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

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

[Enis Bayramoğlu]

I've encountered a very misleading output from `git status`. Here's a
sequence of events that demonstrates the issue:

$ git --version
git version 2.12.0

$ git checkout origin/master

$ git status
HEAD detached from origin/master
nothing to commit, working directory clean

$ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87

$ git status
HEAD detached from origin/master
nothing to commit, working directory clean

$ git rev-parse origin/master
e1dc1baaadee0f1aef2d5c45d068306025d11f67

$ git rev-parse HEAD
786cb6dd09897e0950a2bdc971f0665a059efd33

I think it's extremely misleading that `git status` simply reports
"HEAD detached from origin/master" while this simply happens to be a
mildly relevant fact about some past state.

Thanks and regards

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

[Michael J Gruber]

Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:
> I've encountered a very misleading output from `git status`. Here's a
> sequence of events that demonstrates the issue:
> 
> $ git --version
> git version 2.12.0
> 
> $ git checkout origin/master
> 
> $ git status
> HEAD detached from origin/master
> nothing to commit, working directory clean

Hmm. My Git would display "detached at" here as long as you are on the
commit that you detached from.

> $ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87
> 
> $ git status
> HEAD detached from origin/master
> nothing to commit, working directory clean
> 
> $ git rev-parse origin/master
> e1dc1baaadee0f1aef2d5c45d068306025d11f67
> 
> $ git rev-parse HEAD
> 786cb6dd09897e0950a2bdc971f0665a059efd33
> 
> I think it's extremely misleading that `git status` simply reports
> "HEAD detached from origin/master" while this simply happens to be a
> mildly relevant fact about some past state.
> 
> Thanks and regards
> 

Well, what do you suggest as an alternative?

Git tells you that you are in detached state and where you came from
(detached from).

Michael

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

[Enis Bayramoğlu]

> Well, what do you suggest as an alternative?
>
> Git tells you that you are in detached state and where you came from
> (detached from).

I think it'd be best if git status somehow indicated that you're no
longer at the same commit. Maybe something like:

$ git status
HEAD detached from origin/master, no longer at the same commit
nothing to commit, working directory clean

or, to be more informative

HEAD detached from origin/master 1 commit ago,

On Tue, Apr 11, 2017 at 5:55 PM, Michael J Gruber <git@grubix.eu> wrote:
> Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:
>> I've encountered a very misleading output from `git status`. Here's a
>> sequence of events that demonstrates the issue:
>>
>> $ git --version
>> git version 2.12.0
>>
>> $ git checkout origin/master
>>
>> $ git status
>> HEAD detached from origin/master
>> nothing to commit, working directory clean
>
> Hmm. My Git would display "detached at" here as long as you are on the
> commit that you detached from.
>
>> $ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87
>>
>> $ git status
>> HEAD detached from origin/master
>> nothing to commit, working directory clean
>>
>> $ git rev-parse origin/master
>> e1dc1baaadee0f1aef2d5c45d068306025d11f67
>>
>> $ git rev-parse HEAD
>> 786cb6dd09897e0950a2bdc971f0665a059efd33
>>
>> I think it's extremely misleading that `git status` simply reports
>> "HEAD detached from origin/master" while this simply happens to be a
>> mildly relevant fact about some past state.
>>
>> Thanks and regards
>>
>
> Well, what do you suggest as an alternative?
>
> Git tells you that you are in detached state and where you came from
> (detached from).
>
> Michael

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

[Ævar Arnfjörð Bjarmason]

On Tue, Apr 11, 2017 at 5:13 PM, Enis Bayramoğlu <enis@picussecurity.com> wrote:
>> Well, what do you suggest as an alternative?
>>
>> Git tells you that you are in detached state and where you came from
>> (detached from).
>
> I think it'd be best if git status somehow indicated that you're no
> longer at the same commit. Maybe something like:
>
> $ git status
> HEAD detached from origin/master, no longer at the same commit
> nothing to commit, working directory clean

I'm not saying this is clear, I didn't know this until I read the code
just now, but for what it's worth it says "detached at" if you're
detached from BRANCH but at the same commit, and "detached from" if
you're now on a different commit.

> or, to be more informative
>
> 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.");




> On Tue, Apr 11, 2017 at 5:55 PM, Michael J Gruber <git@grubix.eu> wrote:
>> Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:
>>> I've encountered a very misleading output from `git status`. Here's a
>>> sequence of events that demonstrates the issue:
>>>
>>> $ git --version
>>> git version 2.12.0
>>>
>>> $ git checkout origin/master
>>>
>>> $ git status
>>> HEAD detached from origin/master
>>> nothing to commit, working directory clean
>>
>> Hmm. My Git would display "detached at" here as long as you are on the
>> commit that you detached from.
>>
>>> $ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87
>>>
>>> $ git status
>>> HEAD detached from origin/master
>>> nothing to commit, working directory clean
>>>
>>> $ git rev-parse origin/master
>>> e1dc1baaadee0f1aef2d5c45d068306025d11f67
>>>
>>> $ git rev-parse HEAD
>>> 786cb6dd09897e0950a2bdc971f0665a059efd33
>>>
>>> I think it's extremely misleading that `git status` simply reports
>>> "HEAD detached from origin/master" while this simply happens to be a
>>> mildly relevant fact about some past state.
>>>
>>> Thanks and regards
>>>
>>
>> Well, what do you suggest as an alternative?
>>
>> Git tells you that you are in detached state and where you came from
>> (detached from).
>>
>> Michael

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

[Michael J Gruber]

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
><enis@picussecurity.com> wrote:
>>> Well, what do you suggest as an alternative?
>>>
>>> Git tells you that you are in detached state and where you came from
>>> (detached from).
>>
>> I think it'd be best if git status somehow indicated that you're no
>> longer at the same commit. Maybe something like:
>>
>> $ git status
>> HEAD detached from origin/master, no longer at the same commit
>> nothing to commit, working directory clean
>
>I'm not saying this is clear, I didn't know this until I read the code
>just now, but for what it's worth it says "detached at" if you're
>detached from BRANCH but at the same commit, and "detached from" if
>you're now on a different commit.
>

That's what I explained in my first reply which the OP quoted in a chopped way.  I think he even misquoted the git output he got. 

It's the difference between from and at. 


>> or, to be more informative
>>
>> 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. 

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? 

Maybe improve the doc instead? 

>
>> On Tue, Apr 11, 2017 at 5:55 PM, Michael J Gruber <git@grubix.eu>
>wrote:
>>> Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:
>>>> I've encountered a very misleading output from `git status`. Here's
>a
>>>> sequence of events that demonstrates the issue:
>>>>
>>>> $ git --version
>>>> git version 2.12.0
>>>>
>>>> $ git checkout origin/master
>>>>
>>>> $ git status
>>>> HEAD detached from origin/master
>>>> nothing to commit, working directory clean
>>>
>>> Hmm. My Git would display "detached at" here as long as you are on
>the
>>> commit that you detached from.
>>>
>>>> $ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87
>>>>
>>>> $ git status
>>>> HEAD detached from origin/master
>>>> nothing to commit, working directory clean
>>>>
>>>> $ git rev-parse origin/master
>>>> e1dc1baaadee0f1aef2d5c45d068306025d11f67
>>>>
>>>> $ git rev-parse HEAD
>>>> 786cb6dd09897e0950a2bdc971f0665a059efd33
>>>>
>>>> I think it's extremely misleading that `git status` simply reports
>>>> "HEAD detached from origin/master" while this simply happens to be
>a
>>>> mildly relevant fact about some past state.
>>>>
>>>> Thanks and regards
>>>>
>>>
>>> Well, what do you suggest as an alternative?
>>>
>>> Git tells you that you are in detached state and where you came from
>>> (detached from).
>>>
>>> Michael

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

[Enis Bayramoğlu]

On Wed, Apr 12, 2017 at 8: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
>><enis@picussecurity.com> wrote:
>>>> Well, what do you suggest as an alternative?
>>>>
>>>> Git tells you that you are in detached state and where you came from
>>>> (detached from).
>>>
>>> I think it'd be best if git status somehow indicated that you're no
>>> longer at the same commit. Maybe something like:
>>>
>>> $ git status
>>> HEAD detached from origin/master, no longer at the same commit
>>> nothing to commit, working directory clean
>>
>>I'm not saying this is clear, I didn't know this until I read the code
>>just now, but for what it's worth it says "detached at" if you're
>>detached from BRANCH but at the same commit, and "detached from" if
>>you're now on a different commit.
>>
>
> That's what I explained in my first reply which the OP quoted in a chopped way.  I think he even misquoted the git output he got.
>
> It's the difference between from and at.

You're right, I hadn't noticed the difference, I really thought I
copied the git output verbatim from the console, but I must've been
confused while switching windows. Sorry about that.

I consider myself fairly fluent in English, but it's not my native
language. If you think head detached "from" vs. "at" is immediately
and unambiguously clear about what's going on, then I guess it's not
worth changing the behavior.

>
>
>>> or, to be more informative
>>>
>>> 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.
>
> 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?
>
> Maybe improve the doc instead?
>
>>
>>> On Tue, Apr 11, 2017 at 5:55 PM, Michael J Gruber <git@grubix.eu>
>>wrote:
>>>> Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:
>>>>> I've encountered a very misleading output from `git status`. Here's
>>a
>>>>> sequence of events that demonstrates the issue:
>>>>>
>>>>> $ git --version
>>>>> git version 2.12.0
>>>>>
>>>>> $ git checkout origin/master
>>>>>
>>>>> $ git status
>>>>> HEAD detached from origin/master
>>>>> nothing to commit, working directory clean
>>>>
>>>> Hmm. My Git would display "detached at" here as long as you are on
>>the
>>>> commit that you detached from.
>>>>
>>>>> $ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87
>>>>>
>>>>> $ git status
>>>>> HEAD detached from origin/master
>>>>> nothing to commit, working directory clean
>>>>>
>>>>> $ git rev-parse origin/master
>>>>> e1dc1baaadee0f1aef2d5c45d068306025d11f67
>>>>>
>>>>> $ git rev-parse HEAD
>>>>> 786cb6dd09897e0950a2bdc971f0665a059efd33
>>>>>
>>>>> I think it's extremely misleading that `git status` simply reports
>>>>> "HEAD detached from origin/master" while this simply happens to be
>>a
>>>>> mildly relevant fact about some past state.
>>>>>
>>>>> Thanks and regards
>>>>>
>>>>
>>>> Well, what do you suggest as an alternative?
>>>>
>>>> Git tells you that you are in detached state and where you came from
>>>> (detached from).
>>>>
>>>> Michael
>

Thanks,
Enis

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

[Michael J Gruber]

Enis Bayramoğlu venit, vidit, dixit 12.04.2017 08:15:
> On Wed, Apr 12, 2017 at 8: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
>>> <enis@picussecurity.com> wrote:
>>>>> Well, what do you suggest as an alternative?
>>>>>
>>>>> Git tells you that you are in detached state and where you came from
>>>>> (detached from).
>>>>
>>>> I think it'd be best if git status somehow indicated that you're no
>>>> longer at the same commit. Maybe something like:
>>>>
>>>> $ git status
>>>> HEAD detached from origin/master, no longer at the same commit
>>>> nothing to commit, working directory clean
>>>
>>> I'm not saying this is clear, I didn't know this until I read the code
>>> just now, but for what it's worth it says "detached at" if you're
>>> detached from BRANCH but at the same commit, and "detached from" if
>>> you're now on a different commit.
>>>
>>
>> That's what I explained in my first reply which the OP quoted in a chopped way.  I think he even misquoted the git output he got.
>>
>> It's the difference between from and at.
> 
> You're right, I hadn't noticed the difference, I really thought I
> copied the git output verbatim from the console, but I must've been
> confused while switching windows. Sorry about that.
> 
> I consider myself fairly fluent in English, but it's not my native
> language. If you think head detached "from" vs. "at" is immediately
> and unambiguously clear about what's going on, then I guess it's not
> worth changing the behavior.

I don't mind trying to make this clearer (which is why I asked for
alternatives), I just don't want to reduce the amount of information.
The man pages mentions neither "from" nor "at", so that would be a
starting point.

In fact, I think that "git status [--short]" lacks some of the
information that you only get from, e.g., the git prompt or from "git
checkout" after you switch away. I've set out to amend "git status" with
"in-progress information" (bisecting etc.) in a different thread.

Now for the detached HEAD, I see two variants:

"git branch --list -vv" displays information such as "[origin/next:
ahead 2, behind 3]" for a branch that has diverged from its upstream
"origin/next", and whose upstream has new commits. Mimicking that, git
status could display

HEAD detached from origin/next [ahead 2, behind 3]

either by default or with an extra flag. This requires a "git rev-list
--count --left-right origin/next...HEAD", which is not too bad. The
behind info might be superfluous, but maybe keeping it similar to "git
branch" is beneficial, maybe even more similar:

HEAD detached [from origin/next: ahead 2, behind 3]

"git checkout somewhereElse" display information such as "Warning: you
are leaving 2 commits behind, not connected to any of your branches" and
lists them (the first up to 4). Mimicking that, git status could display

HEAD detached from origin/next [2 orphans]

but this takes more time to compute, especially when you have a lot of
branches. It's the more relevant information in the sense that it counts
those commits that you would loose (once pruned from the reflog) unless
you bind a ref to them or a child commit.

>>
>>
>>>> or, to be more informative
>>>>
>>>> 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.
>>
>> 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?
>>
>> Maybe improve the doc instead?
>>
>>>
>>>> On Tue, Apr 11, 2017 at 5:55 PM, Michael J Gruber <git@grubix.eu>
>>> wrote:
>>>>> Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:
>>>>>> I've encountered a very misleading output from `git status`. Here's
>>> a
>>>>>> sequence of events that demonstrates the issue:
>>>>>>
>>>>>> $ git --version
>>>>>> git version 2.12.0
>>>>>>
>>>>>> $ git checkout origin/master
>>>>>>
>>>>>> $ git status
>>>>>> HEAD detached from origin/master
>>>>>> nothing to commit, working directory clean
>>>>>
>>>>> Hmm. My Git would display "detached at" here as long as you are on
>>> the
>>>>> commit that you detached from.
>>>>>
>>>>>> $ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87
>>>>>>
>>>>>> $ git status
>>>>>> HEAD detached from origin/master
>>>>>> nothing to commit, working directory clean
>>>>>>
>>>>>> $ git rev-parse origin/master
>>>>>> e1dc1baaadee0f1aef2d5c45d068306025d11f67
>>>>>>
>>>>>> $ git rev-parse HEAD
>>>>>> 786cb6dd09897e0950a2bdc971f0665a059efd33
>>>>>>
>>>>>> I think it's extremely misleading that `git status` simply reports
>>>>>> "HEAD detached from origin/master" while this simply happens to be
>>> a
>>>>>> mildly relevant fact about some past state.
>>>>>>
>>>>>> Thanks and regards
>>>>>>
>>>>>
>>>>> Well, what do you suggest as an alternative?
>>>>>
>>>>> Git tells you that you are in detached state and where you came from
>>>>> (detached from).
>>>>>
>>>>> Michael
>>
> 
> Thanks,
> Enis
> 

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

[Ævar Arnfjörð Bjarmason]

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. Saying "diverged"
just makes it clearer, how does it reduce the information we give?

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

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

[Michael J Gruber]

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

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

Michael

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

[Ævar Arnfjörð Bjarmason]

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.

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

[Philip Oakley]

- a bit late in providing a comment..

From: "Michael J Gruber" <git@grubix.eu>
> Æ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.
>
>>> 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?

I think that the doc should highlight the subtelty implied by the at/from
distinction. Especially as users may reasonably think that they are detached 
from a branch, and not see the distinction.

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

As a native UK English speaker (living in Scotland), I focus on the verb
'detached' rather than the at/from distinction. There are many local
dialects and variants so that is only who are taught English as she is wrote
who tend to notice the fine distinctions. (There are many fine Scottish
words which are outwith RP English).

At least if the man page indicated the distinction folks would notice
sooner - they rarely get to see the distinction side by side in the terminal
window.

>
> 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).
>
> Michael
>
--
Philip