Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > Eric Sunshine pointed out that I had such a commit message in > https://public-inbox.org/git/CAPig+cRrS0_nYJJY=O6cboV630sNQHPV5QGrQdD8MW-sYzNFGQ@xxxxxxxxxxxxxx/ > 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 ;-).
