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

Reply via email to