On 14/08/2019 22:20, SZEDER Gábor wrote:
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.
I changed the sequencer to always commit the cherry-pick and then run
'git commit --amend' for rewords [1]. Running
time env GIT_EDITOR=true GIT_SEQUENCE_EDITOR='sed -i s/pick/reword/'
../bin-wrappers/git rebase -i --root
over 100 commits I cannot see any real difference in the timings between
master and that branch. Any difference is within the variation of the
times of multiple runs. The change also fixes a bug when rewording a
re-arranged root commit.
Best Wishes
Phillip
[1] https://github.com/phillipwood/git/commits/wip/rebase-reword-update-head
