105

In Git when I have commits eg. A - B - C and I want to edit the B commit, I

  • use git rebase -i <A-commit-hash>,
  • in the list I write edit command in front of B commit,
  • git rebase stops right after B commit so I can fix anything I want using git commit --amend,
  • and then I continue using git rebase --continue.

As far as I know this is the best practice how to do this. With this method I can edit any commit in the past (as long as it hasn't been pushed to remote branch yet), and moreover with -p flag I can even preserve the merges. This is just great.

My current problem is: I did a mistake (typo) on one line in a merge commit (while resolving a conflict when merging two branches).

I'd like to fix it but I don't know how to make git rebase to stop at a merge commit. The git rebase -p -i <blah> list ignores merge commits, so I cannot write edit command in front of it and make the git rebase stop there to let me edit it.

Any help please? I just want to fix this line in the merge commit while preserving all the commits (and merges) after it.

Thanks.

Improve this question

4 Answers 4

Reset to default
175

Updated answer for 2020:

You can force git rebase -i to stop at the merge commit via the break command (added in Git 2.20). You can then edit the merge commit as desired via git commit --amend.

Detailed steps:

  1. Run git rebase -i --rebase-merges $ancestor_of_merge_commit
  2. Find the merge commit you want to edit in the todo list.
  3. Insert a new line after the merge commit that contains only break (or b).
  4. Save your changes and exit your editor. Git rebase will check out the merge commit, print something like the following, then return you to your prompt: 
    Stopped at fb91fab (Merge branch 'foo' into bar)
  5. Use git commit --amend to edit the merge commit as desired.
  6. Run git rebase --continue when you are done editing the merge commit.

Alternative approach if you do not have any merge commits after the commit you want to edit:

  1. Run git rebase -i $id_of_merge_commit
  2. Insert a new line at the top of the todo list that contains only break (or b).
  3. Save your changes and exit your editor. Git rebase will check out the merge commit, print something like the following, then return you to your prompt: 
    Stopped at fb91fab (Merge branch 'foo' into bar)
  4. Use git commit --amend to edit the merge commit as desired.
  5. Run git rebase --continue when you are done editing the merge commit.

Original answer from 2012 (pre-break):

Git does not make it easy to do interactive rebases when merges are involved. The -p option uses the -i mechanism internally, so mixing the two doesn't really work.

However, git rebase is just an automated way to do lots of cherry-picks. You can replicate its behavior by manually cherry-picking to get a bit more control over the process. It's less convenient and more prone to human error, but possible.

This is the approach I suggest:

  1. use git rebase to get to the commit after the merge (the child of the merge)
  2. use git reset --hard HEAD^ to manually get to the merge
  3. use git commit --amend to repair the merge
  4. use git cherry-pick to get back to the commit after the merge
  5. use git rebase --continue to finish

Here are the specific steps:

  1. Note the SHA1 ID of the merge commit you want to modify. For discussion, suppose it is deadbeef.
  2. Note the SHA1 ID of the commit right after the merge commit you want to modify (the merge commit's child). Suppose it is facef00d.
  3. Run git rebase -i deadbeef.
  4. Select facef00d for editing.
  5. When rebase returns you to a prompt to edit facef00d, run git reset --hard HEAD^. You should now be at deadbeef (git rev-parse HEAD should print deadbeef).
  6. Make your edits to fix the incorrect merge conflict and use git add to stage them.
  7. Run git commit --amend to fuse the staged fix with the bad merge commit. The result will now have a different SHA1 (not deadbeef).
  8. Run git cherry-pick facef00d to apply the changes made by facef00d to the fixed merge commit.
  9. Run git rebase --continue to finish.
Improve this answer
Sign up to request clarification or add additional context in comments.

10 Comments

Nice. I don't mean the process, but the description. :D
So basically I get to the facef00d with git rebase, then I get to the deadbeef manually, fix what I need, and get back to facef00d to finish the rebasing. I was googling this for a few hours and found nothing. Thanks!
@vsechnech: Exactly. I like your high-level description, so I modified my answer to include it.
Nice! Note that one simple way of noting the SHA1 values is to make temporary branches or tags at them.
@Cuadue: rebase refuses to run if there is uncommitted work, so there is no risk of destroying uncommitted work if you follow this procedure.
|
20

This is much easier now with the --rebase-merges option available in Git 2.22 and above. This option preserves the merge topology, and works with interactive rebases.

It'll look something like this, assuming B is the merge commit to amend:

label onto ... some branch definitions ... reset onto merge -C B branch-name # Merge branch 'B' into whatever pick C

You can now insert a b (or break) in between the merge and the pick:

merge -C B branch-name # Merge branch 'xyz' into whatever break pick C

At the break commit --amend the merge, and then continue the rebase.

This also works with a fixup commit. For example, lets say the commit with the fix for the merge is D. You can move your fixup commit D to immediately after the merge commit:

merge -C B branch-name # Merge branch 'xyz' into whatever fixup D pick C

See the Rebasing Merges section of the git-merge man page.

Improve this answer

Comments

1

May be easier to create a fixup commit 'D' then use 'git rebase -p -i <blah>' to reorder 'D' right after 'B' and squash it into 'B'.

pick A pick B <- merge commit to ammend fixup D pick C
Improve this answer

1 Comment

I don't know how to make git rebase to stop at a merge commit is the OPs issue, and mine also. The method you described was my first approach, but I could not get the merge commit to show up in the list to pick.
0

tl;dr: Sometimes you simply shouldn't use git rebase to edit a merge commit. Another method may be more efficient.

I just lived through one such scenario: I had a merge commit which was merging in a very old branch, and there were many conflicts that were resolved in the merge commit. There were some additional commits after the merge, and then it was discovered that a mistake was made in the large merge commit during one file's conflict resolution. I setup the interactive rebase as described in the accepted answer, but when my machine locked up at 2/59 I realized it was writing a lot of files due to re-organizing my file system to match the old branch. After a few minutes I killed it, aborted the rebase, then had to delete 100K files to get back to where I started. Instead of rebase I did this instead:

  1. Make note of the commit IDs I want to replay after I fix the merge commit.
  2. git reset --hard [merge-commit-id]
  3. Make the change and simply amend the HEAD commit (which is the merge commit).
  4. Cherry pick each of the commit IDs in order after the merge commit, or use git rebase --onto with 3 arguments to cherry pick the entire range if there are more than just a few.)

This was much faster.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.