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

["SZEDER Gábor" <szeder.dev@gmail.com>]

On Mon, Aug 12, 2019 at 09:28:52PM +0100, Phillip Wood wrote:
> >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.