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.
