Migrating to Github

As most of developers may already know, Google decided to get rid of another of their products some time ago, Google Code in this case. Moving a Subversion repository to another place is not complex, the problem is that it is not just about source code: the Wiki, the task manager or the contributor list will also dissapear by this year. For Quimera Engine, the only thing that would suppose a notable loss of time would be moving more than 800 tasks that exist in the Issue Tracker, counting both open and closed. Fortunately, Google provided (which is the least they could do) every administrator with a script to make the migration easier to one of many project management platforms with code repository out there: Github. I do not know whether the script was made by either Github's people or Google Code's.

All the problems and necessary changes that had to be done for this project are described below:

  • The directories structure of the repository had to be changed. Git only admits a trunk folder and a branches folder in that repository's root directory. The folder tree in this project was the typical one can find in a SVN repository: trunk, team, tags, branches. When exporting using the script, only trunk and branches folders are exported. Therefore, for the user to find exactly the same structure when entering Github (which shows trunk's content only), everything in the root folder was moved to the trunk folder (so there is one trunk into another).
  • All the commits related to all the folders outside the trunk folder were lost. Although folders were moved as described in the previous point, all the commits associated to the team folder, for example, are lost. All the valuable information about the progress, dates, comments describing solutions, etc. lost.
  • Empty .txt files had to be created inside every empty folder in the repository. Git works with files, not directories, so an empty directory does not exist for it and hence they are not kept in the repository. Some of the SQDirectory's and SQFile's unit tests required the existence of some empty directories, so they have to be created by code now; besides, there were other directories which serve to highlight that certain things are planned but not done yet. There are some hacks to simulate empty folders in Git, but it is not necessary.
  • Status labels had to be created and assigned to every issue. This information is lost during the exportation, only open and closed states are distinguished. For example, an issue whose status is "Ready For Review" (open, ready to be reviewed by someone), this would not appear in the corresponding issue in Github.
  • Although it was not necessary, instead of using labels to know which phase an issue belongs to, they have been removed and replaced with milestones.
  • Obviously, both the web portal and the wiki of the project were updated for all the links to point to the Github's web.

As can be seen, it was not very hard but it was tedious and consumed so much time though. Next paragraphs are not objective anymore and include personal opinions about the new situation.

After fiddling a lot with Github (which I heard a lot about but never tried), I began to make many questions in my mind and to be overwhelmed, mostly after I saw the new Issue Tracker. The following table shows the pros and cons of Github's Issue Tracker compared to Google Code's (note that only features used by this project are considered, there may be better or worse things that do not affect this project):

Pros Cons

Color labels are more visible, if and when there are not so many.

When a list of labels is shown either when assigning to or filtering tasks, the order in which labels appear cannot be controlled. For example, priority labels cannot be put together, a common prefix has to be added.

The issue's description can be edited.

Issues cannot be removed.

Managing and seeing repository branches is easier.

The order in which labels appear in the list of issues cannot be modified.


There are so few options to order the issue list (since there are not either columns or label groups, it is not possible to order by Status, for example)

Filtering is easier.

Filtering by the active user using any kind of wild card is not possible. If I want to see my tasks, I have to select my user in the filter.


There is no "blocked task" concept, hence there is no relation possible among blocked tasks and blocking tasks.


Only 25 tasks can be seen in the list at a time


After discovering this all, my conclusion was clear: making it look pretty was more important than making it practical. The design of the web, in general, is infinitely better than the Google Code's, more modern and accessible, that is undeniable. But regarding the list of issues it is horrible, one of the worst I have seen from the point of view of a person who has to manage more than 10 issues a day, related among each other, with several labels per issue. Sincerely, I expected much more from a tool that hosts such amount of projects and users. Only 25 issues per page? Really? Not to mention that only 15 fit into my 24" screen. And as I remarked before, when there are more than 2 labels per issue, you get dizzy just by looking at it, it is a color party. Call me rare or classic, but I prefer a table in which I can quickly see 100 issues, their priorities, their types, their status, etc.

I do not like to only be complaining, so I began to think about solutions for these kind of inconveniences. In order to obtain more than 25 rows per page, the only alternative (as far as I know) is to call the Github's API, which only makes sense if you create a client to show the results; although it is something simple, I do not have time for that unfortunately. However, I searched for a plug-in for the web browser which let me overwrite the CSS of any web I visited. In effect, there was a quite good one that worked on both Firefox and Chrome, Stylish, whose official web contains a lot of CSS created by users for thousands of different web sites, including Github. However, after looking at the available styles I realized that was not what I wanted (just in case somebody is out of curiosity, there are styles for making the background black, which is interesting if you code in the dark). So I wrote my own CSS and cannot be more satisfied with the result:

Before and after


The style is adjusted to resulotions that are equal or greater than 1680x1050.

Obviously there shall be people who do not like it, but from my point of view it is much more useful this way. All the issues of the page are visible, keeping all the original information, without mixing the title text and the labels; even labels of the same kind appear one under the previous, which makes label value distinction easier.

Summarizing, I understand that everybody has his project at Girhub due to the visibility it provides, because it was one of the first to host Git repositories, even due to the features it offers to look for a job and interacting with others, but really, as a tool for a medium-large project that requires a bit complex management, it is not practical at all.

Finally, I would like to ask the reader to tell me if I am wrong and why, and if anybody knows about a free Github client, be it online or local, please tell me.



0 #1 Thund 2015-05-12 20:42
I've fixed a small error in the CSS file.

You have no rights to post comments