I originally got onto Redmine because of its great out of the box support for git as well as remote subversion repositories. I’m keeping an eye on the “chiliproject” fork of “redmine” at the moment.
I have a redmine installation which includes a few custom modifications. So I have my “local” branch, which forked from redmine’s 1.1-stable some time ago, but when there’s a new version to do, I merge the new redmine version into my local, giving me, for example, redmine 1.1.3 + my changes.
So in order to evaluate chiliproject, and to see if my custom changes would go across, I figured I’d just add the chiliproject git remote and merge it across. Easy right? Well, kind of.
Simply doing this, didn’t work:
$ git remote add chiliproject git://github.com/chiliproject/chiliproject.git
$ git fetch chiliproject
$ git merge chiliproject/stable
This resulted in a *whole bunch* of merge conflicts; many of which actually looked to me like they should have been resolved automatically.
It appears those two repositories have a lot in common, but the main branches I’m interested in (redmine/1.1-stable and chiliproject/stable) have quite a distant common ancestor, which is what git will use to do the merge.
So, check this out:
$ # how many changes have I made from `redmine/1.1-stable`... out of curiosity?
$ git diff redmine/1.1-stable | wc
3340 11917 126173
$ git branch chili-stable chiliproject/stable
$ git checkout chili-stable
$ git merge -s ours redmine/1.1-stable
$ git branch local_chili local_redmine
$ git checkout local_chili
$ git merge chili-stable
$ # merge succeeded, how many changes do I now have from `chiliproject/stable`?
$ git diff chiliproject/stable | wc
3340 11917 126173
And Voila! All of my changes since redmine/1.1-stable can be applied to chiliproject/stable without any conflict. So, when two git repositories are related by difficult to merge, let `git merge -s ours` come to the rescue!