1

I have migrated my project's Subversion repository to Git, as per How to migrate SVN with history to a new Git repository. It worked very well except there is one disconnected branch due to some incorrect use of Subversion in our history. I'm not sure what the terminology is to describe the state of this branch. Here's what it looks like:

trunk: ...-A1--->        <---A3----A4-...

beta:         B1--B2--B3--B4----B5

From what I can tell, this is what happened. At revision B1 a new "beta" branch was created by using cp instead of svn cp. At revisions B4 and A3 the entire repository was moved from /svnroot/project/orig to /svnroot/project (I don't think this is related to the problem but I mention it just in case). At A4 the "beta" branch was merged back into trunk using mv and rm commands instead of svn merge.

How can I fix the Git repository history so that B1 correctly branches from A1 and B5 merges back into A4? Note there are actually 75 revisions in the "beta" branch.

Nathan
  • 5,272
  • 2
  • 26
  • 28

2 Answers2

2

You can use grafts to create fake ancestry information. Create file .git/info/grafts and put something like this into it:

B1 A1
A4 A3 B5

But instead of the names of commits from your schema, put their full SHA1s. After this, make sure that the history looks the way you want it. If it does, you can make the grafts permanent by git filter-branch --all.

Of course, doing this rewrites history and it's a bad idea if anyone else already has a clone of your git repo.

svick
  • 236,525
  • 50
  • 385
  • 514
  • Because the contents of B1 and A1 were identical they couldn't be grafted. I actually needed to graft B2 onto A1. Similarly I had to choose a later version to graft on to B5. Once I got the versions right this worked perfectly. – Nathan Nov 21 '11 at 13:00
0

git checkout beta - take the branch.

git rebase A1 - move beta's commits on top of A1.

git checkout A4 - switch to the A4

git checkout -b new_merge_point - create a temp branch for the merging

git merge beta - the merge. Could be conflicts?!.

git checkout trunk - back to trunk

git rebase new_merge_point reapply commits after A4 to the new merge point.

kan
  • 28,279
  • 7
  • 71
  • 101
  • I think this is not what the OP wants. The merges were already done, trying to make them again will most likely only create lots of conflicts. – svick Nov 16 '11 at 20:29
  • They could be resolved using the A4 as a reference... But yes, manually only, maybe just rewriting all files by A4 (or by soft reset). Looks like your solution is better, however I'm not sure I understand how does it work under the hood. – kan Nov 16 '11 at 20:35
  • Ok, fortunately there is a way to do it better, using `ours` strategy: http://stackoverflow.com/questions/727994/git-skipping-specific-commits-when-merging - it's a way to record a merge with no changes. – kan Nov 18 '11 at 17:26