Re: [PATCH 5/6] status: do not depend on flaky reflog messages

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 14, 2013, 16:31 UTC
Message-ID: <7vsj0kpsb0.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0n_Jsb46qPojbGL3S+mPunNQWUOmypQOvdaBjcT5wgJBg@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 11 quoted lines

> Junio C Hamano wrote:
>> As I said (twice), you can argue that that particular piece of
>> information is not useful (at least to you), but why it is not
>> useful has to be justified, against the justification given by
>> b397ea4863a1 (status: show more info than "currently not on any
>> branch", 2013-03-13) and people who have been using that information
>> in the status output, no?
>
> Yes, Junio.  I cannot justify that "detached HEAD from" is completely
> useless, because it is not.  I argued for a practical compromise, and
> have tried to show the huge negative impact against the marginal gain.

First of all, during a stopped "git rebase", I think "git status" that says "# HEAD detached at" or "# HEAD detached from" is not something we want in the end result anyway. In either case, that comes from the internal use of "git checkout" by the command to switch out of a concrete branch, which is *not* user initiated.

If you first update "git checkout" so that it will pay attention to a custom reflog-action exported by Porcelain scripts that may want to internally use it to flip branches (and without a custom one, it will still record "checkout: moving from A to B"), without exporting custom reflog-action from "rebase" and other Porcelain scripts, that would not affect any externally visible behaviour.

When you teach "git rebase" to pass custom reflog-action when it detaches the HEAD at "$onto^0" (because that is not a user-initiated action) as the next step, nth_prior_checkout and 1st_switch would stop counting them as "checkout" events. That fix will give you the desired result of the topic of this series, i.e. "git checkout @{-1}" ignores the internal "git checkout" done by "rebase".

That step may change the output from "git status" but I do not think the output from "git status" in this sequence:

	git rebase ;# stops upon conflict
        git status

is anything sacred. Tests modified by b397ea4863a1 (status: show more info than "currently not on any branch", 2013-03-13) do change the original "# Not currently on any branch" to "detached at", but I do not think b397ea4863a1 _wanted_ to say where the $onto commit was during the rebase (or was it?), so if they have to change to "detached from", I do not think it is a problem at all. I think it is very sane to update these selected "detached at" to "detached from" as needed.

That would be a sensible compromise, because we do not want to see either "detached at" or "detached from" during "rebase" in the longer term. We would rather want to see the message start with something like

	# Rebasing X on top of Y (23 commits remaining to be replayed)

which is under discussion in a separate thread lately. The change to expected output (i.e. "detached at" to "detached from") will have to be changed again in that separate topic.

The very last test that the b397ea4863a1 added, which wants to see "detached at atag", should be kept, and also there should be another test added to reset one step back to make sure we see "detached from" after it. It tests what the user sees after a "git checkout" initiated by the end-user.