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

[Ramkumar Ramachandra <artagnon@gmail.com>]

Junio C Hamano wrote:
>> At this point, the utility of such a message is in question.
>
> You can question, but I am not convinced the answer is an
> unambiguous "not useful"

I am not arguing for an unambiguous "not useful".  I am arguing for a
practical compromise: this patch locks things up too tightly, and
makes life hell for contributors who want to improve reflog messages.
To be clear: the problem is not the feature, but rather in the
_implementation_ of the feature.

> 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?

>> Moreover,
>> there are several tests in t/status-help that explicitly rely on rebase
>> writing "checkout: " messages to the reflog.  As evidenced by the
>> failing tests in t/checkout-last, these messages are completely
>> unintended and flaky.
>
> The above only helps to convince me that "rebase should not affect
> what the last checked-out branch was by letting 'checkout' it
> internally calls to write reflog entries for it"  With patches 6, 2,
> and 3, I thought you fixed that issue.

I also thought of ignoring the first line in the actual output ("HEAD
detached from/to"), and comparing the rest to make the tests pass.  At
that point, you start to wonder: what is this fantastic feature that
we are bending over backwards for?