Interactive rebase: Git merges commits even if I don't want to

Question

This problem is kinda difficult to describe without sharing the full repo, but I'll try.

I realized I had made a mistake in the last but one commit. I decided to fix it using interactive rebase.

git rebase -i @~~

Now I'm taken to Vim, where I change the command in the first line:

pick 80c90b55788 First commit message  <-- change 'pick' to 'edit'
pick 712be094f96 Second commit message

Git responds with:

Stopped at 80c90b55788...  First commit message
You can amend the commit now, with
    git commit --amend 
Once you are satisfied with your changes, run
    git rebase --continue

I modify the find that needs a fix (I delete the offending line). Then I continue with:

git add <file>
git commit --amend
git rebase --continue

Now git detects a conflict in the file I edited. (Two consecutive lines were deleted - one originally in the second commit, the other one that I've deleted in the previous step.) To me, this step looks superfluous, as Git basically does the right thing - it has merged the changes correctly. But it waits for me to stage the changes.

Without any modifications to the file, I do again:

git add <file>
git commit --amend
git rebase --continue

Git reponds with:

Successfully rebased and updated refs/heads/mybranch.

BAM Now the two commits are merged into one. The result contains changes from both commits. The first commit message is used.

What is the reason? I just wanted to modify the last but one commit and let git to rebase the second commit onto it.

Answer 1

If you have conflicts while rebasing, you must not call git commit --amend . Once you have resolved the conflict and staged the changes, call git rebase --continue .

Even with action "edit", the git commit --amend step is redundant. While editing, calling git rebase --continue will automatically amend the commit being currently edited.