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:
>>> 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.