git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: "SZEDER Gábor" <szeder.dev@gmail.com>,
	git@vger.kernel.org,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: minor interactive rebase regression: HEAD points to wrong commit while rewording
Date: Thu, 15 Aug 2019 09:54:44 -0700	[thread overview]
Message-ID: <xmqqlfvu4be3.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <xmqqpnl64c94.fsf@gitster-ct.c.googlers.com> (Junio C. Hamano's message of "Thu, 15 Aug 2019 09:36:07 -0700")

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

> Phillip Wood <phillip.wood123@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	other threads:[~2019-08-15 16:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-12 17:50 minor interactive rebase regression: HEAD points to wrong commit while rewording SZEDER Gábor
2019-08-12 18:17 ` Junio C Hamano
2019-08-12 18:56   ` SZEDER Gábor
2019-08-12 20:28 ` Phillip Wood
2019-08-14 20:45   ` Johannes Schindelin
2019-08-14 21:40     ` SZEDER Gábor
2019-08-14 21:20   ` SZEDER Gábor
2019-08-15 13:47     ` Phillip Wood
2019-08-15 16:36       ` Junio C Hamano
2019-08-15 16:54         ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqlfvu4be3.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood123@gmail.com \
    --cc=szeder.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).