Re: `git status` output is very misleading after a merge on a "detached HEAD"

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Apr 12, 2017 at 3:11 PM, Michael J Gruber <git@grubix.eu> wrote:
> Ævar Arnfjörð Bjarmason venit, vidit, dixit 12.04.2017 14:18:
>> On Wed, Apr 12, 2017 at 7:43 AM, Michael J Gruber <git@grubix.eu> wrote:
>>> Am 11. April 2017 22:40:14 MESZ schrieb "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>:
>>>> On Tue, Apr 11, 2017 at 5:13 PM, Enis Bayramoğlu
>>>>> HEAD detached from origin/master 1 commit ago,
>>>>
>>>> In lieu of that, which would need some of the rev-list machinery to be
>>>> invoked on every git-status, I wonder if just saying "HEAD detached &
>>>> diverged from origin/master" wouldn't be clearer:
>>>>
>>>> diff --git a/wt-status.c b/wt-status.c
>>>> index 308cf3779e..79c8cfd1cf 100644
>>>> --- a/wt-status.c
>>>> +++ b/wt-status.c
>>>> @@ -1542,7 +1542,7 @@ static void wt_longstatus_print(struct wt_status
>>>> *s)
>>>>                                if (state.detached_at)
>>>>                                      on_what = _("HEAD detached at ");
>>>>                                else
>>>> -                                       on_what = _("HEAD detached from
>>>> ");
>>>> +                                       on_what = _("HEAD detached &
>>>> diverged from ");
>>>>                        } else {
>>>>                                branch_name = "";
>>>>                           on_what = _("Not currently on any branch.");
>>>>
>>>>
>>>>
>>>
>>> No way. That would reduce the information that we give.
>>
>> How does it reduce the information we give? Maybe I've missed
>> something about what "from" means here, as opposed to "at", but it
>> seems to me to mean the same thing as "diverged" by definition, i.e.
>> we detached from the branch but we diverged from it.
>
> No, "at" means we're still at that commit - detached but not diverged.
> "from" means we only started from that commit, but are not at it any more.
>
>> Saying "diverged"
>> just makes it clearer, how does it reduce the information we give?
>
> I misread your patch on my mobile phone, sorry. I thought you meant to
> replace both "at" and "from" by "diverged from" because you considered
> them synonymous.
>
> But your patch touches just the" from" case and emphasizes the "diverge"
> aspect, which is fine, of course.

Ah, that explains the confusion. Yeah saying "diverged" for the "at"
case wouldn't make any sense, there's been no divergence.

>>> Note that the difference between from and at is also: are there commits that we could lose when we switch away, that is: that git checkout would warn us about?
>>
>> Right, but I don't see how that's in any way conflicting or mutually
>> exclusive with saying before hand that we've diverged from the branch.
>>
>>> Maybe improve the doc instead?
>>
>> Aside from whether my patch makes any sense, the solution to a UX
>> issue really can't be "oh this just needs to be documented". For every
>> user who's confused by some interface we provide a *tiny* minority of
>> them go and exhaustively read the docs for an explanation, will just
>> remain confused.
>>
>> I think saying from v.s. at is way too subtle, I for one have been
>> missing it for years until this thread, that's bad UX, git's also used
>> by a lot of non-native English speakers who may not at all get the
>> subtle difference between at and from in this context, or if they do
>> think the UI is using that subtlety to tell them something.
>
> Well, we have to find the right balance between clarity and brevity - an
> interface that is too chatty is a nightmare. That's why I suggested both
> doc changes and additional information.
>
> What do you think about the ahead/behind info as suggested? That should
> be more informative both qualitatively (something diverged) and
> quantitatively (by how much).

I think it's better UX, but worry about placing something like
revision walking into "git status", that can take a long time. E.g. on
linux.git doing:

    git checkout origin/master
    git reset --hard v2.6.13

Will yield:

    $ time echo "[ahead $(git rev-list origin/master..HEAD|wc -l),
behind $(git rev-list HEAD..origin/master|wc -l)]"
    [ahead 1, behind 657045]
    real    0m7.859s

That's admittedly a very pathological case, and could be solved in
practice by changing the copy so that after e.g. 100 commits we start
saying "over 100 commits ahead..." or something like that.