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.
--amendon the conflict resolution case is bad user-experience. It's something you have to get used to in Git.--amendis prescribed there: By replacing the command "pick" with the command "edit", you can tellgit rebaseto stop after applying that commit, so that you can edit the files and/or the commit message, amend the commit, and continue rebasing.edit(where Git stops, but not because of conflict resolution). Why? Because Git exposes you to the raw internal details of how commits work, instead of providing a proper user experience, that's why. :-) Git works pretty well (which is why it's beaten up so much of its competition), but it has a terrible set of interfaces.edit, the new-and-improved commit is made at that point. If you wish to replace that commit usinggit commityou must usegit commit --amend. But when the new-and-improved commit isn't made yet, and you usegit commit --amend, you're amending the previous commit (one that was made, or was already there), which is what people call "squashing" or a "fixup" (combining two commits).git rebase --interactivewas first written) the rebase code was smartened up enough to do the appropriate kind ofgit commitfor you if and when necessary, but the documentation still describes the original "the programmer must be very careful and precise about which operation he is finishing now" sequence of operations. Probably the documentation should just say "you can now edit your working tree, rungit add, and rungit rebase --continue" although the internal tests would need to be updated to match.