Github migration

[continuing from [ ]

The topic of the migration to Github has been raised a number of times over the last few years. Over the time, the support for this proposal has been steadily raising and now it is the time to make the decision.

The proposal is to:

  1. change version control system from SVN to Git
  2. change repository host provider from sourceforge to github

Git is superior over SVN in several important ways:

  • your local working copy is a repository itself. You can commit intermediate changes without sending them to the central repository. This significantly helps in developemnt and storing various experiments.
  • better support for branches, making it much easier to develop features over extended period of time without breaking the trunk. It is also much easier to develop several features concurrently.
  • local copy stores the full history, so operations like log or blame are de facto instant

Github is superior over Sourceforge in several important ways:

  • support for “pull request” — easy way for contributors outside the core team to submit their changes
  • sane repository and commit browser
  • support for reviewing the code

The main drawback of Git that was poor Windows support is now largely gone:

  • Visual Studio 2013 features built-in Git support. It is incomplete but quite convienient for the most common operations (pulling changes from repo, committing and pushing your own changes; branches management).
  • TortoiseGit is ugly and inconvenient. Yet, it allows doing everything that you need in a familiar GUI (for those, who used TortoiseSVN).
  • if you absolutely cannot use Git, Github supports also using SVN clients … subversion

So the only serious drawback I see is that we’ll end up with ugly hashes for identifying commits instead of revision numbers that I like so much. Well, that can’t be helped.

Please let me know:

  • if you’re OK with the migration (feedback so far has been either neutral or positive, however I want to be sure)
  • if you have any preferences when the migration should occur
  • if you have suggestions on how the migration should be technically realized (I don’t have any experience and will rely on whatever the google spits out)
  • there is anything else to add (or to remove) :slight_smile:
  1. Github has its own client to work with git, as I’ve heard it’s more or less convenient.
  2. command-line git is better :wink:
  1. Before moving to git we should define EOL rules. Inconsistent EOLs just a bit annoying with SVN but may be real problem with Git.
  2. We should define workflow (if we want feature branches to be in main repo, allowing to collaborate not only in “master”).


  1. Neutral towards git, although I like features that distributed VCS can offer (like better branches). And quite positive towards github features specifically.
  2. Anytime you want. Worst thing that may happen is that I’ll have to move some diff’s from svn repo to git.

As for migration:

  • I remember something about line endings - github does not like mixing Win/Unix line ends or something like that. Anyway it is probably a good idea to unify line endings during (or immediately after) migration.

  • It seems that right now only you and me have full access (thanks BTW). Does anyone else needs to post their profile names or you’ve handled this already?

  • Github offers its own issue tracker and wiki. What we should do with them?

    • Wiki - disable completely or place redirect to Don’t see any use in it for us.
    • Tracker - disabling it is easy. Or maybe keep it as well as Mantis? So it can be used by those who are too lazy to register on Mantis and/or for github-specific issues (like that Travis support)
  • Readme file. Completely useless in current form. Github displays it below repository so quite a lot of people will see it. I think it can be considered as front page of repository. Somebody must rewrite it completely. Example of nice readme in a similar project:

  • Since with git it is possible to develop new features in branches perhaps we should decide how master branch should be used? And document this properly ofc. For example:

    • before merge somebody must review, preferably with different compiler (gcc or clang vs msvc)
    • keep one feature/bugfix per commit. Commits can be done locally and then merged to master as part of (bigger) branch without spamming commit log as we had in svn.
  • Debatable, but perfect time for such changes. I would also support reorganization of our source tree - right now our root directory is quite a mess.

    • remove some garbage files like NEWS (empty) or COPYING (one-liner that refers to license.txt)
    • create “src” directory and move client, lib, server, etc in it
    • create “data” directory and move config and Mods in it
    • move project files into separate “projects” directory, if possible?

Oh yes, it is. How will we be able to track all the bugs, especially among many branches?

For me, only ease of use is necessary. Can learn new features over time, just don’t want to waste time fighthing repo and tools.

Re Github’s tracker: I suggest to choose only one option. We, in SuperTuxKart, had github tracket and Trac and it was such a mess when tickets started to be duplicated.

I’m new to Git, so I informed me about the different kinds of workflows you can use with Git. This page has a good introduction to Git including a few examples: (in german). The part about pull requests is written in english. There a few nice advantages for Git over SVN. That’s the typical workflow when adding a new feature or fixing a greater bug:

  1. A developer creates the feature in a dedicated branch in their local repo.
  2. The developer pushes the branch to a public repository.
  3. The developer files a pull request.
  4. The rest of the team reviews the code, discusses it, and alters it.
  5. The project maintainer merges the feature into the official repository and closes the pull request.

Copied from the site mentioned above. The review and discussion part is great. Currently I’m moving some level up logic from server to lib and a few things should be reviewed or discussed before commiting to master / trunk. So it would be nice if work in progress can be reviewed by others, while keeping trunk or master in a working stable state. BTW, will write PM to you Tow, soon :slight_smile:

I would vote for unix/linux and mac line endings:)

Perhaps someone could also rewrite AUTHORS file. The site you mentioned has a nice authors file as well.

Good point! I don’t really like it if I get some compiler errors about template stuff:)

I would say new features, experiments, greater refactorings or greater bugfixes should be done on a new branch. For the rest it’s OK to work directly on master.

+1! Is it possible to locate CMakeLists in separate directories? I think it should be possible for MSVC. Where should we locate our package subfolders rpm, osx and debian?

I haven’t seen anything better than “Pro Git”:

Mixed line endings don’t cause any trouble. The Git provides an option to automatically convert line endings on commit/checkout, so every developer can have line endings native to his system when developing and they are converted to the normalzied ones when uploading changes. … ne-endings … ent-operat

Yes, I’ll need to collect github account names and e-mails of all contributors. Please PM me.
I hope Github will properly join commits with the accounts after import.


At the moment I see no use for them.
Mantis remains our bugtracker. If we decided to accept reports via github issues tool, we would need someone who would be responsible for creating a paired report on Mantis. I see your point about people not wanting to be bothered with registering on our bugtracker but I don’t think we should at the moment concern ourselves with that.
The same problem is present also in VCMI-related threads on various forums. Eg. I see a number of bugreports in our HC thread that don’t make to the Mantis. I’d say that accepting issues from Github tool is part of bigger endeavour that is “accepting issue reports by other channels than Mantis”. Certainly worthy to be discussed, not necessarily here. [And we’d need a volunteer with some time to manage such reports.]

I’ll think about this. There numerous approaches. Eg

Yet, I think that we shouldn’t change too much at once. First swithc to git and get accustomed to it while still allowing the “traditional” workflow. More complex workflows and rules can be introduced later.

Not sure how feasible it is in our current team.

Very good, important point. Commits should be focused and atomic. It makes later much easier track when the bug appeared or to revert one particular change.

Possible. MSVC projects can live happily anywhere.

AFAIR it was once decided that Unix (single LF byte) line endings should be used.

Is it anyhow related that github mirror does not get refreshed anymore?

Apparently. I converted VCMI account into organization and now it cannot push commits.
Well, we’ll have a real one soon enough.

I’ve been developing a lot using git in the recent half year. I think the Gitflow Workflow is the easiest to grasp coming from SVN, and I guess I also really like it overall. Basically you have two fixed branches, master and develop where *develop *is a branch of master. *master *is equivalent of the SVN tags and *develop *is equivalent to SVN trunk.

When someone wants to implement a feature they make a branch from develop. When they’re finished they merge, or make pull request for merging, their branch into *develop *so that other developers branching from *develop *can pull these changes into their own branch.
When it’s time to tag a new release, a developer simply makes a pull request from *develop *to *master *with the version number as commit message or equivalent.

If it feels like too much overhead dealing with code reviews and such you can skip having pull requests and just let all developers push directly into *develop *(this would be the same as just commiting to *trunk *in SVN).