Re: minor interactive rebase regression: HEAD points to wrong commit while rewording

On Mon, Aug 12, 2019 at 09:28:52PM +0100, Phillip Wood wrote:

quoted

Save the updated commit message, and after the editor opens up the
third commit's log message, check again where HEAD is pointing to now:

  ~/tmp/reword (master +|REBASE-i 2/3)$ head -n1 .git/COMMIT_EDITMSG
  third
  ~/tmp/reword (master +|REBASE-i 2/3)$ git log --oneline -1
  c3db735 (HEAD) second - updated

As second has been updated the sequencer cannot fast-forward to third so it
cherry-picks third and then passes --edit when it runs 'git commit' to
commit the cherry-pick. HEAD is updated once the reworded commit has been
created.

I think the scripted rebase always ran cherry-pick and then ran 'commit
--amend' afterwards if the commit was being reworded. The C implementation
is more efficient as it avoids creating an redundant commit but has the side
effect that HEAD is not updated before the reword which was surprising here.

I'm not sure about this more efficient thing.  I mean, 'git rebase' is
about to launch the editor to let the user type something...  Compared
to that the time spent in creating an extra commit object is surely
negligible.