Re: [PATCH v3 0/4] rebase -i: avoid stale "# This is a combination of" in commit messages

Johannes Schindelin [off-list ref] writes:

Eric Sunshine pointed out that I had such a commit message in
https://public-inbox.org/git/CAPig+cRrS0_nYJJY=O6cboV630sNQHPV5QGrQdD8MW-sYzNFGQ@mail.gmail.com/
and I went on a hunt to figure out how the heck this happened.

Turns out that if there is a fixup/squash chain where the *last* command
fails with merge conflicts, and we either --skip ahead or resolve the
conflict to a clean tree and then --continue, our code does not do a
final cleanup.

Contrary to my initial gut feeling, this bug was not introduced by my
rewrite in C of the core parts of rebase -i, but it looks to me as if
that bug was with us for a very long time (at least the --skip part).

The developer (read: user of rebase -i) in me says that we would want to
fast-track this, but the author of rebase -i in me says that we should
be cautious and cook this in `next` for a while.

Fixes since v2 (thanks, Stefan!):

- Fixed commit message of 2/4: "Thisis" -> "This is".

- Reinstated the order where the `message-squash` file is renamed to
  `message` first, and only if that succeeded, we delete the
  `message-fixup` file.

base-commit: fe0a9eaf31dd0c349ae4308498c33a5c3794b293

This round looks reasonable (the last one was already so, though
;-).  As this is not a recent regression, however, I think we would
want to have it regardless of recent updates to rebase-i that is
happening on the 'next down to master' front.

I've queued this round using base-commit of d32eb83c ("Git 2.16.3",
2018-03-22), the same base as the previous round, for that reason.

Merging it to the tip of 'master' and applying these patches
directly on top of 'master' result in identical trees, of course
(otherwise we wouldn't be able to maintain the stable releases and
make forward progress on the 'master' front at the same time ;-).