Menu
I have started using Git in the middle of my project, where the first two commits are just some initial settings (.gitignore and .gitattributes), and the third commit M2 adds the content of the SVN trunk:
I1 -- I2 -- M2 -- N -- .. -- Z I have imported the SVN history in a branch named svn, where M1 is the SVN trunk (with the same content as M2, except .gitignore and .gitattributes):
A -- B -- ... -- K -- L -- M1 Q: What is the best approach in merging both branches?
I could merge M1 and M2 into M3, and then rebase, but I don't know how to delete the I1 and I2 commits and if I can safely remove the M3 commit (I have found some advices to preserve the merge commits, but in this case M3 it's not necessary anymore).
A -- B -- ... -- K -- L -- M1 \ M3 -- N' -- .. -- Z' / I1 -- I2 -- M2 -- N -- .. -- Z Another way would be to cherry-pick the N .. Z commits into svn branch by hand, but I would like to avoid this approach.
The most elegant solution would be to rebase the changes introduced by N .. Z commits on top of svn branch, but I didn't found yet the required syntax for two branches without a common ancestor.
529
But this doesn't mean that Git cannot perform any merge. In fact, all you need to do to merge unrelated branches is to use the flag --allow-unrelated-histories . This tells Git to combine all the files and commits of both unrelated branches into one branch, as long as there are no file conflicts.
To merge branches locally, use git checkout to switch to the branch you want to merge into. This branch is typically the main branch. Next, use git merge and specify the name of the other branch to bring into this branch. This example merges the jeff/feature1 branch into the main branch.
The alternative (and longer) way of fixing the fatal: refusing to merge unrelated histories issues is to unstage your current commits, stash them, clone your required remote repository, and then place your stashed branch contents into the new clone.
Disclaimer: I've only used "graft points" myself once in a toy repository. But it is an obscure feature which you may not have heard of, and which _may_ be helpful in your situation.
You could use "graft points" to fake the ancestry information. See, e.g., What are .git/info/grafts for? or proceed immediately to the git wiki entry on graft points.
In essence, you would create a file .git/info/grafts that tricks git into thinking that commit M1 is an ancestor of commit M2:
$ cat .git/info/grafts <your M2 commit hash> <your M1 commit hash> Subsequently, it would look like M2 was an empty commit that just merged I2 and M1 into a common tree.
The major downside: the graft point is not committed; therefore, it is not checked out, but needs to be added to each local working copy of the repository manually.
Update: use git replace --graft instead.
Graft points, as described above, have been superseded. Run
git replace --graft <your M2 commit hash> <your M1 commit hash> to create the graft. This is stored in .git/refs/replace/. Although git does not fetch, or push, these refs by default, they can be synchronized between repositories using:
git push origin 'refs/replace/*' git fetch origin 'refs/replace/*:refs/replace/*' (StackOverflow: How to push 'refs/replace' without pushing any other refs in git?)
131
The most elegant solution would be to rebase the changes introduced by N .. Z commits on top of svn branch, but I didn't found yet the required syntax for two branches without a common ancestor.
Try to first cherry-pick I1 and I2 onto M1, and after that use the command git rebase --onto M1' M2 Z (where M1' is the M1-I1-I2 branch). I'm not sure whether rebase --onto works when there are no common ancestors, but if it doesn't, there is the possibility of using patches. Use the git format-patch to generate the patches of M2..Z and then git am to apply them on top of M1. Here are some experience reports on using it in converting old SVN and CVS repositories.
20
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
