Junio C Hamano <gits...@pobox.com> writes:

> Phillip Wood <phillip.wood...@gmail.com> 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.

Reply via email to