3

I have something akin to the following history (but more complicated with several merges):

        F - G - H - K - L - …
       /           /
      /       I - J - M - …
     /       /
A - B - C - D - E - …

A′- B′- C′- D′- E′

A and A′ are identical trees with different histories.

I want to rebase all branch commits to equivalent commits on the prime branch, preserving merges (presumably by manually specifying the hashes of where the equivalent commits are on the rebased tree). How do I tell K′ that it needs to merge from H′ and J′? Or do I have to recreate these merge commits manually?

If I do git rebase -p --onto B′ B L it fails to apply cleanly. I could rebase H onto B′ and M onto D′, and then recreate merge K myself, then rebase L onto K′ (and so on for other branches/merges not shown) but it would be a fair bit of work.

I have looked at several other questions but none of them featured merges.

Community
  • 1
  • 1
Nicholas Shanks
  • 10,623
  • 4
  • 56
  • 80
  • Is your repo private, or is it publicly accessible on GitHub? If it's public, people could take a look directly. –  Feb 19 '14 at 19:50
  • If this is a private repo, then you should be able to accomplish this with `git filter-branch --parent-filter ... --all`, where the script for the parent filter identifies `B` and declares that it's new parent should be `A'` instead of `A`. You probably will want to add a `--tag-name-filter cat` to preserve any tags in the parts you're rewriting. If it's a public repo, though, this might be inadvisable. Looks like you could also use `--commit-filter`, but it's more general... – twalberg Feb 19 '14 at 21:19

2 Answers2

3

Assuming this is either not a public repository, or any other users of the repository are ok with significant rewriting, the most efficient way to accomplish this is with git filter-branch. One of the possible filters is --parent-filter, which allows you to change the parentage of specific commits, somewhat similarly to grafting or rebasing a portion of the tree, but since you can also pass the --all option, you can accomplish the effect on multiple branches in one invocation. This could also be accomplished with a --commit-filter; but that's a more general solution intended for changing other aspects of individual commits - not just the parents. You'd probably also want to use a --tag-name-filter cat to move any tags in the portions of the tree being rewritten.

So the final command would look something like:

git filter-branch --parent-filter <somescript> --tag-name-filter cat -- --all

where <somescript> is either properly quoted/escaped bash code to replace A with A' for the B commit (details on exactly how the information is provided to the script and what the results of the script should be can be found in git help filter-branch), or the name of an actual shell script that accomplishes the same.

There is also some cleanup to be done afterwards - filter-branch leaves your original branches in place, but with new names (refs/original/...) so you can recover if something doesn't look right. There's plenty of information out there on how to remove dead branches once you're satisfied that filter-branch did what you wanted, and re-packing your repository to recover the storage space, so I won't replicate that here...

twalberg
  • 59,951
  • 11
  • 89
  • 84
  • I needed a double dash before the `--all` flag as that flag is sent to a sub-command: `git filter-branch -f --parent-filter 'test $GIT_COMMIT = HASH_OF_B && echo "-p HASH_OF_A_PRIME" || cat' -- --all` but otherwise it worked. Thank you. – Nicholas Shanks Feb 20 '14 at 10:57
1

Have you tried using interactive rebasing? Basically, do git rebase -i A and git will fire up your text editor with the commits after A listed. You can then move commits around and squash commits into each other to your heart's content.

Zhehao Mao
  • 1,789
  • 13
  • 13