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.
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.