Junio C Hamano <gitster@xxxxxxxxx> writes: > Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > >> On 14/08/2019 22:20, SZEDER Gábor wrote: >> >> 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. > > I guess that settles the "efficiency" story; besides, showing a > wrong intermediate state to users and scripts efficiently is just as > bad as showing a wrong state less efficiently. Needless to say, there is no need for us to make things less efficient when we do not need to. If there are two back-to-back "pick"s, and there is no hook and the like that gives an end-user and/or a script a reliable trigger point that can be used to "observe" and "utilize" the state immediately after the first "pick", we do not have to update the HEAD (or update the working tree for that matter) between these two "pick"s. The external process being able to observe alone is not an enough reason to force us go inefficient here---if the triggering event is like "spawn an editor and wait for it to exit", that gives the external process to not just "observe" the updated state after the first pick, but also "utilize" that state (e.g. build, compare with some other tree, etc.) knowing that the second "pick" does not start changing the state until it relinquishes the control. But unless the external process can reliably utilize the updated state, it is of not much use to just be able to notice the change. For example, an argument like "constantly monitoring changes in the $GIT_DIR/rebase-merge directory, we can notice that each 'pick' gets done" is not a reason to force us to update HEAD every time any instruction is consumed in the todo file, as the next "pick" cannot be reliably delayed by somebody who is merely observing the directory to utilize the updated state.
