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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:

> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]