Recently I have faced some strange git merging issue.
My team uses git and we have our own git and build servers and we are happy about that. But our mysterious deployment system is still configured to use svn (shame on us). Besides other guys also work with svn. Svn server has three years of history and is used for deployment. My team don't really need all the history so we just made "svn export" of the latest revision and uploaded sources to the git server.
It is great, history is not messy, a successful Git branching model and so on. But there is still a necessity to merge changes back to svn when sprint is finished. And here the problem comes...
Even thought "svn" and "git" team didn't have a lot of conflicting files, merge back using git-svn was inexplicably hard: when we exported svn branch to git from same starting revision and tried to merge two branches we got conflicts for all changed files, but not only real conflicts. It was also hard to solve conflicts because there were not any base version of files, two-way merge only. The problem is that we made just svn export without any history so git and git-svn branches don't have anything common.
This is very odd since git is tracking file content but not a structure, isn't it?
The solution is tree following steps:
1. Merge the git-svn starting point commit to the git branch:git checkout master git merge -s ours git_svn_starting_point_commit_idThis merge won't do anything but interconnect git and git-svn branches so they are not totally different any more.
2. Main merge git branch to svn:
git checkout git-svn-trunk git merge --squash masterAt this point you would probably have some conflicts, but there are much less files and now you would have a base version so it is possible to use tree-way merge while solving conflicts.
3. Commit you changes to svn:
git commit -a -m "Merge form git master." git svn rebase git svn dcommitDone!
Using two different version control systems is quite painful so just use git and be happy :-)