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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 15, 2013, 09:58 UTC
Message-ID: <7vobb7lmpi.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0mCK_-bUapAvcrwtNgGnT1=x1d=+J9RO1GK6ssHWP2ztA@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 7 quoted lines

> 2. The following no longer updates status:
>
>   # in the middle of a rebase
>   $ git reset @~2
>
> The constant "HEAD detached at $onto" message is misleading and Bad.
> Besides, wasn't this the primary usecase you wanted?

See the other message. The first line from status in the middle of a rebase is secondary. End-user initiated "checkout" to detach is the primary thing.

Show 8 quoted lines

> You previously wrote:
>> *1* One thing I could think of is to start sightseeing or (more
>>     realistically) manually bisecting at a given release point,
>>     reset the detached HEAD around several times, and then want to
>>     be reminded where the session started from.  I do not think it
>>     is particularly a very good example, though.
>
> Whether the HEAD is detached by bisect or rebase is irrelevant.

You read and reacted to "bisect" too literally and missed "manually". The scenario I had in mind does _not_ use "git bisect" command, which may _internally_ run "git checkout" to detach, but for exactly the same reason why you want to touch "git rebase" in this series, its use of "checkout" should not count for the next "checkout -".

The sequence of "manually bisecting" is like

	$ git checkout v1.8.3
        ... test
        $ git status
        $ git log --oneline --first-parent v1.8.2..$detached_from
        ... pick a likely point
        $ git reset --hard $that_point
        ... go back to test further

which I actually do fairly often, as I tend to know more about the likely place something may have been broken than a mechanical "split the history into about the same number of commits" bisection.

> 3. The problem is not unique to rebase at all; yet you have
> special-cased it.  If this isn't a band-aid, what is?

It is an illustration for approach (2) in the other message.

In the longer term, you would want richer status output for various detached state, and that "how about this" patch shows where new code to support other cases should be added.