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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 13, 2013, 21:02 UTC
Message-ID: <7vd2rpu3kf.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0kjxKFkrLArL1mLZYCMN1=sgnDSa3vaoJm6eSUp2E4Pyw@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> To be clear: the problem is not the feature, but rather in the
> _implementation_ of the feature.

OK, but are we discussing the same "feature" (see below)?

Show 14 quoted lines

>> You were at 1.8.2 but no longer are, so in the following sequence:
>>
>>     $ git checkout v1.8.2
>>     $ git status
>>     $ git reset --hard HEAD^
>>     $ git status
>>
>> the former would say "detached at v1.8.2" while the latter should
>> *not*, because we are no longer at v1.8.2.  "detached from v1.8.2"
>> is too subtle a way to express the state, and is confusing, but I
>> would not be surprised if people find it useful to be able to learn
>> "v1.8.2" even after you strayed away.
>
> What is wrong with git describe?  Is this cheaper, or am I missing something?

I think what you are missing is that the "detached from" is not about your current HEAD after you flipped it around with many resets and commits. It is about what tag or what specific commit you detached your HEAD at originally.

"You can ask the same to describe" is wrong and is not a valid argument. Once you replace the HEAD^ with a distant commit (e.g. HEAD~400) in the third step in the example, "describe" will not talk about v1.8.2 at all.

Your argument can be that it is not a useful piece of information, and as you can probably guess from my "I wouldn't be surprised" above, I am not sure how useful it would be and in what situation [*1*].

But the original commit thought it was necessary and that was done for a reason; we need to be careful here. With a good justification why it is not necessary (or misleading to the user), I do not think we cannot change it.

As various tools that use detached "intermediate" states leave enough clues for "status" to notice what is going on, I actually think it is a mistake to focus on what happens when we are in such a detached "intermediate" status with this codepath. For example:

	$ git rebase master
        ... replays some but stops
        $ git status

currently uses that "HEAD detached from" codepath, but I think that is a mistake. We could not just tell the HEAD is detached, but the reason _why_ the HEAD is detached (i.e. we are in the middle of a rebase). The prompt script can do it, "status" should be able to do the same, and do a lot more sensible thing than unconditionally showing that "HEAD detached from" and then say "You are currently rebasing" on a separate line. Most likely we do not want to even say "Not currently on any branch" but just say "You are currently rebasing branch X on top of Y" (and perhaps "N commits remaining to be replayed").

[Footnote]

*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.