92

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.

vasekch
  • 1,207
  • 1
  • 10
  • 9

4 Answers4

149

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.
Richard Hansen
  • 51,690
  • 20
  • 90
  • 97
  • 5
    Nice. I don't mean the process, but the description. :D – vhallac Mar 31 '12 at 17:50
  • 2
    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! – vasekch Apr 02 '12 at 12:03
  • 2
    @vsechnech: Exactly. I like your high-level description, so I modified my answer to include it. – Richard Hansen Apr 02 '12 at 16:12
  • 2
    Nice! Note that one simple way of noting the SHA1 values is to make temporary branches or tags at them. – mabraham May 31 '13 at 17:18
  • `git reset --hard` carries the risk of destroying uncommitted work. Can you do this without the hard reset? – Cuadue Sep 17 '14 at 21:36
  • 2
    @Cuadue: `rebase` refuses to run if there is uncommitted work, so there is no risk of destroying uncommitted work if you follow this procedure. – Richard Hansen Sep 17 '14 at 22:05
  • It is error-prone, but actually pretty safe: if I screwed up in any step before the last, I can always get back with `git rebase --abort` and start over. I just need to double-check (very carefully) *right before* the last step. – Franklin Yu Jan 29 '17 at 08:03
  • 1
    Can't steps 1,2 and 4 be avoided by using break before the first commit? Basically, ``git rebase -i merge-commit-sha``, then b at the very top, then amend the merge commit and ``git rease --continue``. – FRob Nov 17 '20 at 18:38
  • Great answer, when it works. I just had one (admittedly rare) scenario where this was horribly inefficient, and added an answer with an easy workaround. – TTT Jan 21 '21 at 22:42
  • Your 2020 edit is pretty much a copy of my answer. – Raman Mar 14 '21 at 06:00
12

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.

Raman
  • 17,606
  • 5
  • 95
  • 112
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
i3ensays
  • 2,804
  • 3
  • 19
  • 23
  • 4
    _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. – Nathan Kidd Nov 15 '18 at 14:45
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.

TTT
  • 22,611
  • 8
  • 63
  • 69