{"thread":{"id":"45660","subject":"`git status` output is very misleading after a merge on a \"detached HEAD\"","startedAt":"2017-04-11T08:57:10Z","lastAt":"2017-04-14T16:32:27Z","messageCount":11,"participants":["Enis Bayramoğlu","Michael J Gruber","Ævar Arnfjörð Bjarmason","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"316560","messageId":"CAMLReHYBVmuu5H015N1ShCD0iLNau9oLOabJhQ7xc=58rXQi+Q@mail.gmail.com","threadId":"45660","inReplyTo":null,"subject":"`git status` output is very misleading after a merge on a \"detached HEAD\"","fromName":"Enis Bayramoğlu","fromEmail":"enis@picussecurity.com","sentAt":"2017-04-11T08:57:00Z","receivedAt":"2017-04-11T08:57:10Z","isPatch":false,"sender":{"key":"enis@picussecurity.com","avatar":null},"body":"I've encountered a very misleading output from `git status`. Here's a\nsequence of events that demonstrates the issue:\n\n$ git --version\ngit version 2.12.0\n\n$ git checkout origin/master\n\n$ git status\nHEAD detached from origin/master\nnothing to commit, working directory clean\n\n$ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87\n\n$ git status\nHEAD detached from origin/master\nnothing to commit, working directory clean\n\n$ git rev-parse origin/master\ne1dc1baaadee0f1aef2d5c45d068306025d11f67\n\n$ git rev-parse HEAD\n786cb6dd09897e0950a2bdc971f0665a059efd33\n\nI think it's extremely misleading that `git status` simply reports\n\"HEAD detached from origin/master\" while this simply happens to be a\nmildly relevant fact about some past state.\n\nThanks and regards\n"},{"id":"316595","messageId":"88df8638-9b7b-42c4-bb34-4e1a49d4c22d@grubix.eu","threadId":"45660","inReplyTo":"CAMLReHYBVmuu5H015N1ShCD0iLNau9oLOabJhQ7xc=58rXQi+Q@mail.gmail.com","subject":"Re: `git status` output is very misleading after a merge on a \"detached HEAD\"","fromName":"Michael J Gruber","fromEmail":"git@grubix.eu","sentAt":"2017-04-11T14:55:11Z","receivedAt":"2017-04-11T14:55:33Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:\n> I've encountered a very misleading output from `git status`. Here's a\n> sequence of events that demonstrates the issue:\n> \n> $ git --version\n> git version 2.12.0\n> \n> $ git checkout origin/master\n> \n> $ git status\n> HEAD detached from origin/master\n> nothing to commit, working directory clean\n\nHmm. My Git would display \"detached at\" here as long as you are on the\ncommit that you detached from.\n\n> $ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87\n> \n> $ git status\n> HEAD detached from origin/master\n> nothing to commit, working directory clean\n> \n> $ git rev-parse origin/master\n> e1dc1baaadee0f1aef2d5c45d068306025d11f67\n> \n> $ git rev-parse HEAD\n> 786cb6dd09897e0950a2bdc971f0665a059efd33\n> \n> I think it's extremely misleading that `git status` simply reports\n> \"HEAD detached from origin/master\" while this simply happens to be a\n> mildly relevant fact about some past state.\n> \n> Thanks and regards\n> \n\nWell, what do you suggest as an alternative?\n\nGit tells you that you are in detached state and where you came from\n(detached from).\n\nMichael\n"},{"id":"316598","messageId":"CAMLReHYbuHmGTtBSUQq3bO=6ghz=rfP-=Eg=PvP0tkwZbM2Q1Q@mail.gmail.com","threadId":"45660","inReplyTo":"88df8638-9b7b-42c4-bb34-4e1a49d4c22d@grubix.eu","subject":"Re: `git status` output is very misleading after a merge on a \"detached HEAD\"","fromName":"Enis Bayramoğlu","fromEmail":"enis@picussecurity.com","sentAt":"2017-04-11T15:13:37Z","receivedAt":"2017-04-11T15:13:44Z","isPatch":false,"sender":{"key":"enis@picussecurity.com","avatar":null},"body":"> Well, what do you suggest as an alternative?\n>\n> Git tells you that you are in detached state and where you came from\n> (detached from).\n\nI think it'd be best if git status somehow indicated that you're no\nlonger at the same commit. Maybe something like:\n\n$ git status\nHEAD detached from origin/master, no longer at the same commit\nnothing to commit, working directory clean\n\nor, to be more informative\n\nHEAD detached from origin/master 1 commit ago,\n\nOn Tue, Apr 11, 2017 at 5:55 PM, Michael J Gruber wrote:\n> Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:\n>> I've encountered a very misleading output from `git status`. Here's a\n>> sequence of events that demonstrates the issue:\n>>\n>> $ git --version\n>> git version 2.12.0\n>>\n>> $ git checkout origin/master\n>>\n>> $ git status\n>> HEAD detached from origin/master\n>> nothing to commit, working directory clean\n>\n> Hmm. My Git would display \"detached at\" here as long as you are on the\n> commit that you detached from.\n>\n>> $ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87\n>>\n>> $ git status\n>> HEAD detached from origin/master\n>> nothing to commit, working directory clean\n>>\n>> $ git rev-parse origin/master\n>> e1dc1baaadee0f1aef2d5c45d068306025d11f67\n>>\n>> $ git rev-parse HEAD\n>> 786cb6dd09897e0950a2bdc971f0665a059efd33\n>>\n>> I think it's extremely misleading that `git status` simply reports\n>> \"HEAD detached from origin/master\" while this simply happens to be a\n>> mildly relevant fact about some past state.\n>>\n>> Thanks and regards\n>>\n>\n> Well, what do you suggest as an alternative?\n>\n> Git tells you that you are in detached state and where you came from\n> (detached from).\n>\n> Michael\n"},{"id":"316643","messageId":"CACBZZX7xqoZ3LboOjwvQvX3JRJFhjFC54+mfLOddLXzconrobw@mail.gmail.com","threadId":"45660","inReplyTo":"CAMLReHYbuHmGTtBSUQq3bO=6ghz=rfP-=Eg=PvP0tkwZbM2Q1Q@mail.gmail.com","subject":"Re: `git status` output is very misleading after a merge on a \"detached HEAD\"","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-11T20:40:14Z","receivedAt":"2017-04-11T20:40:40Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Apr 11, 2017 at 5:13 PM, Enis Bayramoğlu wrote:\n>> Well, what do you suggest as an alternative?\n>>\n>> Git tells you that you are in detached state and where you came from\n>> (detached from).\n>\n> I think it'd be best if git status somehow indicated that you're no\n> longer at the same commit. Maybe something like:\n>\n> $ git status\n> HEAD detached from origin/master, no longer at the same commit\n> nothing to commit, working directory clean\n\nI'm not saying this is clear, I didn't know this until I read the code\njust now, but for what it's worth it says \"detached at\" if you're\ndetached from BRANCH but at the same commit, and \"detached from\" if\nyou're now on a different commit.\n\n> or, to be more informative\n>\n> HEAD detached from origin/master 1 commit ago,\n\nIn lieu of that, which would need some of the rev-list machinery to be\ninvoked on every git-status, I wonder if just saying \"HEAD detached &\ndiverged from origin/master\" wouldn't be clearer:\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 308cf3779e..79c8cfd1cf 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -1542,7 +1542,7 @@ static void wt_longstatus_print(struct wt_status *s)\n if (state.detached_at)\n on_what = _(\"HEAD detached at \");\n else\n- on_what = _(\"HEAD detached from \");\n+ on_what = _(\"HEAD detached &\ndiverged from \");\n } else {\n branch_name = \"\";\n on_what = _(\"Not currently on any branch.\");\n\n\n\n\n> On Tue, Apr 11, 2017 at 5:55 PM, Michael J Gruber wrote:\n>> Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:\n>>> I've encountered a very misleading output from `git status`. Here's a\n>>> sequence of events that demonstrates the issue:\n>>>\n>>> $ git --version\n>>> git version 2.12.0\n>>>\n>>> $ git checkout origin/master\n>>>\n>>> $ git status\n>>> HEAD detached from origin/master\n>>> nothing to commit, working directory clean\n>>\n>> Hmm. My Git would display \"detached at\" here as long as you are on the\n>> commit that you detached from.\n>>\n>>> $ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87\n>>>\n>>> $ git status\n>>> HEAD detached from origin/master\n>>> nothing to commit, working directory clean\n>>>\n>>> $ git rev-parse origin/master\n>>> e1dc1baaadee0f1aef2d5c45d068306025d11f67\n>>>\n>>> $ git rev-parse HEAD\n>>> 786cb6dd09897e0950a2bdc971f0665a059efd33\n>>>\n>>> I think it's extremely misleading that `git status` simply reports\n>>> \"HEAD detached from origin/master\" while this simply happens to be a\n>>> mildly relevant fact about some past state.\n>>>\n>>> Thanks and regards\n>>>\n>>\n>> Well, what do you suggest as an alternative?\n>>\n>> Git tells you that you are in detached state and where you came from\n>> (detached from).\n>>\n>> Michael\n"},{"id":"316668","messageId":"5704E476-BD11-47D1-A15E-C1E29A1398AD@grubix.eu","threadId":"45660","inReplyTo":"CACBZZX7xqoZ3LboOjwvQvX3JRJFhjFC54+mfLOddLXzconrobw@mail.gmail.com","subject":"Re: `git status` output is very misleading after a merge on a \"detached HEAD\"","fromName":"Michael J Gruber","fromEmail":"git@grubix.eu","sentAt":"2017-04-12T05:43:19Z","receivedAt":"2017-04-12T05:43:29Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Am 11. April 2017 22:40:14 MESZ schrieb \"Ævar Arnfjörð Bjarmason\" :\n>On Tue, Apr 11, 2017 at 5:13 PM, Enis Bayramoğlu\n> wrote:\n>>> Well, what do you suggest as an alternative?\n>>>\n>>> Git tells you that you are in detached state and where you came from\n>>> (detached from).\n>>\n>> I think it'd be best if git status somehow indicated that you're no\n>> longer at the same commit. Maybe something like:\n>>\n>> $ git status\n>> HEAD detached from origin/master, no longer at the same commit\n>> nothing to commit, working directory clean\n>\n>I'm not saying this is clear, I didn't know this until I read the code\n>just now, but for what it's worth it says \"detached at\" if you're\n>detached from BRANCH but at the same commit, and \"detached from\" if\n>you're now on a different commit.\n>\n\nThat'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. \n\nIt's the difference between from and at. \n\n\n>> or, to be more informative\n>>\n>> HEAD detached from origin/master 1 commit ago,\n>\n>In lieu of that, which would need some of the rev-list machinery to be\n>invoked on every git-status, I wonder if just saying \"HEAD detached &\n>diverged from origin/master\" wouldn't be clearer:\n>\n>diff --git a/wt-status.c b/wt-status.c\n>index 308cf3779e..79c8cfd1cf 100644\n>--- a/wt-status.c\n>+++ b/wt-status.c\n>@@ -1542,7 +1542,7 @@ static void wt_longstatus_print(struct wt_status\n>*s)\n> if (state.detached_at)\n> on_what = _(\"HEAD detached at \");\n> else\n>- on_what = _(\"HEAD detached from\n>\");\n>+ on_what = _(\"HEAD detached &\n>diverged from \");\n> } else {\n> branch_name = \"\";\n> on_what = _(\"Not currently on any branch.\");\n>\n>\n>\n\nNo way. That would reduce the information that we give. \n\nNote 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? \n\nMaybe improve the doc instead? \n\n>\n>> On Tue, Apr 11, 2017 at 5:55 PM, Michael J Gruber \n>wrote:\n>>> Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:\n>>>> I've encountered a very misleading output from `git status`. Here's\n>a\n>>>> sequence of events that demonstrates the issue:\n>>>>\n>>>> $ git --version\n>>>> git version 2.12.0\n>>>>\n>>>> $ git checkout origin/master\n>>>>\n>>>> $ git status\n>>>> HEAD detached from origin/master\n>>>> nothing to commit, working directory clean\n>>>\n>>> Hmm. My Git would display \"detached at\" here as long as you are on\n>the\n>>> commit that you detached from.\n>>>\n>>>> $ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87\n>>>>\n>>>> $ git status\n>>>> HEAD detached from origin/master\n>>>> nothing to commit, working directory clean\n>>>>\n>>>> $ git rev-parse origin/master\n>>>> e1dc1baaadee0f1aef2d5c45d068306025d11f67\n>>>>\n>>>> $ git rev-parse HEAD\n>>>> 786cb6dd09897e0950a2bdc971f0665a059efd33\n>>>>\n>>>> I think it's extremely misleading that `git status` simply reports\n>>>> \"HEAD detached from origin/master\" while this simply happens to be\n>a\n>>>> mildly relevant fact about some past state.\n>>>>\n>>>> Thanks and regards\n>>>>\n>>>\n>>> Well, what do you suggest as an alternative?\n>>>\n>>> Git tells you that you are in detached state and where you came from\n>>> (detached from).\n>>>\n>>> Michael\n\n"},{"id":"316669","messageId":"CAMLReHa2M=h+cWm_9qqiL0n+E1+AFzHXqiBG45fGiGUBTdkseg@mail.gmail.com","threadId":"45660","inReplyTo":"5704E476-BD11-47D1-A15E-C1E29A1398AD@grubix.eu","subject":"Re: `git status` output is very misleading after a merge on a \"detached HEAD\"","fromName":"Enis Bayramoğlu","fromEmail":"enis@picussecurity.com","sentAt":"2017-04-12T06:15:47Z","receivedAt":"2017-04-12T06:15:55Z","isPatch":false,"sender":{"key":"enis@picussecurity.com","avatar":null},"body":"On Wed, Apr 12, 2017 at 8:43 AM, Michael J Gruber wrote:\n> Am 11. April 2017 22:40:14 MESZ schrieb \"Ævar Arnfjörð Bjarmason\" :\n>>On Tue, Apr 11, 2017 at 5:13 PM, Enis Bayramoğlu\n>> wrote:\n>>>> Well, what do you suggest as an alternative?\n>>>>\n>>>> Git tells you that you are in detached state and where you came from\n>>>> (detached from).\n>>>\n>>> I think it'd be best if git status somehow indicated that you're no\n>>> longer at the same commit. Maybe something like:\n>>>\n>>> $ git status\n>>> HEAD detached from origin/master, no longer at the same commit\n>>> nothing to commit, working directory clean\n>>\n>>I'm not saying this is clear, I didn't know this until I read the code\n>>just now, but for what it's worth it says \"detached at\" if you're\n>>detached from BRANCH but at the same commit, and \"detached from\" if\n>>you're now on a different commit.\n>>\n>\n> 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.\n>\n> It's the difference between from and at.\n\nYou're right, I hadn't noticed the difference, I really thought I\ncopied the git output verbatim from the console, but I must've been\nconfused while switching windows. Sorry about that.\n\nI consider myself fairly fluent in English, but it's not my native\nlanguage. If you think head detached \"from\" vs. \"at\" is immediately\nand unambiguously clear about what's going on, then I guess it's not\nworth changing the behavior.\n\n>\n>\n>>> or, to be more informative\n>>>\n>>> HEAD detached from origin/master 1 commit ago,\n>>\n>>In lieu of that, which would need some of the rev-list machinery to be\n>>invoked on every git-status, I wonder if just saying \"HEAD detached &\n>>diverged from origin/master\" wouldn't be clearer:\n>>\n>>diff --git a/wt-status.c b/wt-status.c\n>>index 308cf3779e..79c8cfd1cf 100644\n>>--- a/wt-status.c\n>>+++ b/wt-status.c\n>>@@ -1542,7 +1542,7 @@ static void wt_longstatus_print(struct wt_status\n>>*s)\n>> if (state.detached_at)\n>> on_what = _(\"HEAD detached at \");\n>> else\n>>- on_what = _(\"HEAD detached from\n>>\");\n>>+ on_what = _(\"HEAD detached &\n>>diverged from \");\n>> } else {\n>> branch_name = \"\";\n>> on_what = _(\"Not currently on any branch.\");\n>>\n>>\n>>\n>\n> No way. That would reduce the information that we give.\n>\n> 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?\n>\n> Maybe improve the doc instead?\n>\n>>\n>>> On Tue, Apr 11, 2017 at 5:55 PM, Michael J Gruber \n>>wrote:\n>>>> Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:\n>>>>> I've encountered a very misleading output from `git status`. Here's\n>>a\n>>>>> sequence of events that demonstrates the issue:\n>>>>>\n>>>>> $ git --version\n>>>>> git version 2.12.0\n>>>>>\n>>>>> $ git checkout origin/master\n>>>>>\n>>>>> $ git status\n>>>>> HEAD detached from origin/master\n>>>>> nothing to commit, working directory clean\n>>>>\n>>>> Hmm. My Git would display \"detached at\" here as long as you are on\n>>the\n>>>> commit that you detached from.\n>>>>\n>>>>> $ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87\n>>>>>\n>>>>> $ git status\n>>>>> HEAD detached from origin/master\n>>>>> nothing to commit, working directory clean\n>>>>>\n>>>>> $ git rev-parse origin/master\n>>>>> e1dc1baaadee0f1aef2d5c45d068306025d11f67\n>>>>>\n>>>>> $ git rev-parse HEAD\n>>>>> 786cb6dd09897e0950a2bdc971f0665a059efd33\n>>>>>\n>>>>> I think it's extremely misleading that `git status` simply reports\n>>>>> \"HEAD detached from origin/master\" while this simply happens to be\n>>a\n>>>>> mildly relevant fact about some past state.\n>>>>>\n>>>>> Thanks and regards\n>>>>>\n>>>>\n>>>> Well, what do you suggest as an alternative?\n>>>>\n>>>> Git tells you that you are in detached state and where you came from\n>>>> (detached from).\n>>>>\n>>>> Michael\n>\n\nThanks,\nEnis\n"},{"id":"316678","messageId":"4d5f14ff-a886-bdca-126b-0261c4d33de1@grubix.eu","threadId":"45660","inReplyTo":"CAMLReHa2M=h+cWm_9qqiL0n+E1+AFzHXqiBG45fGiGUBTdkseg@mail.gmail.com","subject":"Re: `git status` output is very misleading after a merge on a \"detached HEAD\"","fromName":"Michael J Gruber","fromEmail":"git@grubix.eu","sentAt":"2017-04-12T11:36:19Z","receivedAt":"2017-04-12T11:36:29Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Enis Bayramoğlu venit, vidit, dixit 12.04.2017 08:15:\n> On Wed, Apr 12, 2017 at 8:43 AM, Michael J Gruber wrote:\n>> Am 11. April 2017 22:40:14 MESZ schrieb \"Ævar Arnfjörð Bjarmason\" :\n>>> On Tue, Apr 11, 2017 at 5:13 PM, Enis Bayramoğlu\n>>> wrote:\n>>>>> Well, what do you suggest as an alternative?\n>>>>>\n>>>>> Git tells you that you are in detached state and where you came from\n>>>>> (detached from).\n>>>>\n>>>> I think it'd be best if git status somehow indicated that you're no\n>>>> longer at the same commit. Maybe something like:\n>>>>\n>>>> $ git status\n>>>> HEAD detached from origin/master, no longer at the same commit\n>>>> nothing to commit, working directory clean\n>>>\n>>> I'm not saying this is clear, I didn't know this until I read the code\n>>> just now, but for what it's worth it says \"detached at\" if you're\n>>> detached from BRANCH but at the same commit, and \"detached from\" if\n>>> you're now on a different commit.\n>>>\n>>\n>> 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.\n>>\n>> It's the difference between from and at.\n> \n> You're right, I hadn't noticed the difference, I really thought I\n> copied the git output verbatim from the console, but I must've been\n> confused while switching windows. Sorry about that.\n> \n> I consider myself fairly fluent in English, but it's not my native\n> language. If you think head detached \"from\" vs. \"at\" is immediately\n> and unambiguously clear about what's going on, then I guess it's not\n> worth changing the behavior.\n\nI don't mind trying to make this clearer (which is why I asked for\nalternatives), I just don't want to reduce the amount of information.\nThe man pages mentions neither \"from\" nor \"at\", so that would be a\nstarting point.\n\nIn fact, I think that \"git status [--short]\" lacks some of the\ninformation that you only get from, e.g., the git prompt or from \"git\ncheckout\" after you switch away. I've set out to amend \"git status\" with\n\"in-progress information\" (bisecting etc.) in a different thread.\n\nNow for the detached HEAD, I see two variants:\n\n\"git branch --list -vv\" displays information such as \"[origin/next:\nahead 2, behind 3]\" for a branch that has diverged from its upstream\n\"origin/next\", and whose upstream has new commits. Mimicking that, git\nstatus could display\n\nHEAD detached from origin/next [ahead 2, behind 3]\n\neither by default or with an extra flag. This requires a \"git rev-list\n--count --left-right origin/next...HEAD\", which is not too bad. The\nbehind info might be superfluous, but maybe keeping it similar to \"git\nbranch\" is beneficial, maybe even more similar:\n\nHEAD detached [from origin/next: ahead 2, behind 3]\n\n\"git checkout somewhereElse\" display information such as \"Warning: you\nare leaving 2 commits behind, not connected to any of your branches\" and\nlists them (the first up to 4). Mimicking that, git status could display\n\nHEAD detached from origin/next [2 orphans]\n\nbut this takes more time to compute, especially when you have a lot of\nbranches. It's the more relevant information in the sense that it counts\nthose commits that you would loose (once pruned from the reflog) unless\nyou bind a ref to them or a child commit.\n\n>>\n>>\n>>>> or, to be more informative\n>>>>\n>>>> HEAD detached from origin/master 1 commit ago,\n>>>\n>>> In lieu of that, which would need some of the rev-list machinery to be\n>>> invoked on every git-status, I wonder if just saying \"HEAD detached &\n>>> diverged from origin/master\" wouldn't be clearer:\n>>>\n>>> diff --git a/wt-status.c b/wt-status.c\n>>> index 308cf3779e..79c8cfd1cf 100644\n>>> --- a/wt-status.c\n>>> +++ b/wt-status.c\n>>> @@ -1542,7 +1542,7 @@ static void wt_longstatus_print(struct wt_status\n>>> *s)\n>>> if (state.detached_at)\n>>> on_what = _(\"HEAD detached at \");\n>>> else\n>>> - on_what = _(\"HEAD detached from\n>>> \");\n>>> + on_what = _(\"HEAD detached &\n>>> diverged from \");\n>>> } else {\n>>> branch_name = \"\";\n>>> on_what = _(\"Not currently on any branch.\");\n>>>\n>>>\n>>>\n>>\n>> No way. That would reduce the information that we give.\n>>\n>> 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?\n>>\n>> Maybe improve the doc instead?\n>>\n>>>\n>>>> On Tue, Apr 11, 2017 at 5:55 PM, Michael J Gruber \n>>> wrote:\n>>>>> Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:\n>>>>>> I've encountered a very misleading output from `git status`. Here's\n>>> a\n>>>>>> sequence of events that demonstrates the issue:\n>>>>>>\n>>>>>> $ git --version\n>>>>>> git version 2.12.0\n>>>>>>\n>>>>>> $ git checkout origin/master\n>>>>>>\n>>>>>> $ git status\n>>>>>> HEAD detached from origin/master\n>>>>>> nothing to commit, working directory clean\n>>>>>\n>>>>> Hmm. My Git would display \"detached at\" here as long as you are on\n>>> the\n>>>>> commit that you detached from.\n>>>>>\n>>>>>> $ git merge --ff f3515b749be861b57fc70c2341c1234eeb0d5b87\n>>>>>>\n>>>>>> $ git status\n>>>>>> HEAD detached from origin/master\n>>>>>> nothing to commit, working directory clean\n>>>>>>\n>>>>>> $ git rev-parse origin/master\n>>>>>> e1dc1baaadee0f1aef2d5c45d068306025d11f67\n>>>>>>\n>>>>>> $ git rev-parse HEAD\n>>>>>> 786cb6dd09897e0950a2bdc971f0665a059efd33\n>>>>>>\n>>>>>> I think it's extremely misleading that `git status` simply reports\n>>>>>> \"HEAD detached from origin/master\" while this simply happens to be\n>>> a\n>>>>>> mildly relevant fact about some past state.\n>>>>>>\n>>>>>> Thanks and regards\n>>>>>>\n>>>>>\n>>>>> Well, what do you suggest as an alternative?\n>>>>>\n>>>>> Git tells you that you are in detached state and where you came from\n>>>>> (detached from).\n>>>>>\n>>>>> Michael\n>>\n> \n> Thanks,\n> Enis\n> \n"},{"id":"316680","messageId":"CACBZZX4W1kk2cnncWz1EVjA-WtFryYzNoiiDHR9+9VC4AKJhKg@mail.gmail.com","threadId":"45660","inReplyTo":"5704E476-BD11-47D1-A15E-C1E29A1398AD@grubix.eu","subject":"Re: `git status` output is very misleading after a merge on a \"detached HEAD\"","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-12T12:18:38Z","receivedAt":"2017-04-12T12:19:05Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 12, 2017 at 7:43 AM, Michael J Gruber wrote:\n> Am 11. April 2017 22:40:14 MESZ schrieb \"Ævar Arnfjörð Bjarmason\" :\n>>On Tue, Apr 11, 2017 at 5:13 PM, Enis Bayramoğlu\n>>> HEAD detached from origin/master 1 commit ago,\n>>\n>>In lieu of that, which would need some of the rev-list machinery to be\n>>invoked on every git-status, I wonder if just saying \"HEAD detached &\n>>diverged from origin/master\" wouldn't be clearer:\n>>\n>>diff --git a/wt-status.c b/wt-status.c\n>>index 308cf3779e..79c8cfd1cf 100644\n>>--- a/wt-status.c\n>>+++ b/wt-status.c\n>>@@ -1542,7 +1542,7 @@ static void wt_longstatus_print(struct wt_status\n>>*s)\n>> if (state.detached_at)\n>> on_what = _(\"HEAD detached at \");\n>> else\n>>- on_what = _(\"HEAD detached from\n>>\");\n>>+ on_what = _(\"HEAD detached &\n>>diverged from \");\n>> } else {\n>> branch_name = \"\";\n>> on_what = _(\"Not currently on any branch.\");\n>>\n>>\n>>\n>\n> No way. That would reduce the information that we give.\n\nHow does it reduce the information we give? Maybe I've missed\nsomething about what \"from\" means here, as opposed to \"at\", but it\nseems to me to mean the same thing as \"diverged\" by definition, i.e.\nwe detached from the branch but we diverged from it. Saying \"diverged\"\njust makes it clearer, how does it reduce the information we give?\n\n> 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?\n\nRight, but I don't see how that's in any way conflicting or mutually\nexclusive with saying before hand that we've diverged from the branch.\n\n> Maybe improve the doc instead?\n\nAside from whether my patch makes any sense, the solution to a UX\nissue really can't be \"oh this just needs to be documented\". For every\nuser who's confused by some interface we provide a *tiny* minority of\nthem go and exhaustively read the docs for an explanation, will just\nremain confused.\n\nI think saying from v.s. at is way too subtle, I for one have been\nmissing it for years until this thread, that's bad UX, git's also used\nby a lot of non-native English speakers who may not at all get the\nsubtle difference between at and from in this context, or if they do\nthink the UI is using that subtlety to tell them something.\n"},{"id":"316685","messageId":"61ef36d9-7f25-80d6-5216-554684bd54dd@grubix.eu","threadId":"45660","inReplyTo":"CACBZZX4W1kk2cnncWz1EVjA-WtFryYzNoiiDHR9+9VC4AKJhKg@mail.gmail.com","subject":"Re: `git status` output is very misleading after a merge on a \"detached HEAD\"","fromName":"Michael J Gruber","fromEmail":"git@grubix.eu","sentAt":"2017-04-12T13:11:50Z","receivedAt":"2017-04-12T13:12:02Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Ævar Arnfjörð Bjarmason venit, vidit, dixit 12.04.2017 14:18:\n> On Wed, Apr 12, 2017 at 7:43 AM, Michael J Gruber wrote:\n>> Am 11. April 2017 22:40:14 MESZ schrieb \"Ævar Arnfjörð Bjarmason\" :\n>>> On Tue, Apr 11, 2017 at 5:13 PM, Enis Bayramoğlu\n>>>> HEAD detached from origin/master 1 commit ago,\n>>>\n>>> In lieu of that, which would need some of the rev-list machinery to be\n>>> invoked on every git-status, I wonder if just saying \"HEAD detached &\n>>> diverged from origin/master\" wouldn't be clearer:\n>>>\n>>> diff --git a/wt-status.c b/wt-status.c\n>>> index 308cf3779e..79c8cfd1cf 100644\n>>> --- a/wt-status.c\n>>> +++ b/wt-status.c\n>>> @@ -1542,7 +1542,7 @@ static void wt_longstatus_print(struct wt_status\n>>> *s)\n>>> if (state.detached_at)\n>>> on_what = _(\"HEAD detached at \");\n>>> else\n>>> - on_what = _(\"HEAD detached from\n>>> \");\n>>> + on_what = _(\"HEAD detached &\n>>> diverged from \");\n>>> } else {\n>>> branch_name = \"\";\n>>> on_what = _(\"Not currently on any branch.\");\n>>>\n>>>\n>>>\n>>\n>> No way. That would reduce the information that we give.\n> \n> How does it reduce the information we give? Maybe I've missed\n> something about what \"from\" means here, as opposed to \"at\", but it\n> seems to me to mean the same thing as \"diverged\" by definition, i.e.\n> we detached from the branch but we diverged from it.\n\nNo, \"at\" means we're still at that commit - detached but not diverged.\n\"from\" means we only started from that commit, but are not at it any more.\n\n> Saying \"diverged\"\n> just makes it clearer, how does it reduce the information we give?\n\nI misread your patch on my mobile phone, sorry. I thought you meant to\nreplace both \"at\" and \"from\" by \"diverged from\" because you considered\nthem synonymous.\n\nBut your patch touches just the\" from\" case and emphasizes the \"diverge\"\naspect, which is fine, of course.\n\n>> 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?\n> \n> Right, but I don't see how that's in any way conflicting or mutually\n> exclusive with saying before hand that we've diverged from the branch.\n> \n>> Maybe improve the doc instead?\n> \n> Aside from whether my patch makes any sense, the solution to a UX\n> issue really can't be \"oh this just needs to be documented\". For every\n> user who's confused by some interface we provide a *tiny* minority of\n> them go and exhaustively read the docs for an explanation, will just\n> remain confused.\n> \n> I think saying from v.s. at is way too subtle, I for one have been\n> missing it for years until this thread, that's bad UX, git's also used\n> by a lot of non-native English speakers who may not at all get the\n> subtle difference between at and from in this context, or if they do\n> think the UI is using that subtlety to tell them something.\n\nWell, we have to find the right balance between clarity and brevity - an\ninterface that is too chatty is a nightmare. That's why I suggested both\ndoc changes and additional information.\n\nWhat do you think about the ahead/behind info as suggested? That should\nbe more informative both qualitatively (something diverged) and\nquantitatively (by how much).\n\nMichael\n"},{"id":"316687","messageId":"CACBZZX4Fkvbqz-ynKwsoj8c4dYZxjjW-OkQbM=SNePL1HAPxkw@mail.gmail.com","threadId":"45660","inReplyTo":"61ef36d9-7f25-80d6-5216-554684bd54dd@grubix.eu","subject":"Re: `git status` output is very misleading after a merge on a \"detached HEAD\"","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-12T13:30:12Z","receivedAt":"2017-04-12T13:31:32Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 12, 2017 at 3:11 PM, Michael J Gruber wrote:\n> Ævar Arnfjörð Bjarmason venit, vidit, dixit 12.04.2017 14:18:\n>> On Wed, Apr 12, 2017 at 7:43 AM, Michael J Gruber wrote:\n>>> Am 11. April 2017 22:40:14 MESZ schrieb \"Ævar Arnfjörð Bjarmason\" :\n>>>> On Tue, Apr 11, 2017 at 5:13 PM, Enis Bayramoğlu\n>>>>> HEAD detached from origin/master 1 commit ago,\n>>>>\n>>>> In lieu of that, which would need some of the rev-list machinery to be\n>>>> invoked on every git-status, I wonder if just saying \"HEAD detached &\n>>>> diverged from origin/master\" wouldn't be clearer:\n>>>>\n>>>> diff --git a/wt-status.c b/wt-status.c\n>>>> index 308cf3779e..79c8cfd1cf 100644\n>>>> --- a/wt-status.c\n>>>> +++ b/wt-status.c\n>>>> @@ -1542,7 +1542,7 @@ static void wt_longstatus_print(struct wt_status\n>>>> *s)\n>>>> if (state.detached_at)\n>>>> on_what = _(\"HEAD detached at \");\n>>>> else\n>>>> - on_what = _(\"HEAD detached from\n>>>> \");\n>>>> + on_what = _(\"HEAD detached &\n>>>> diverged from \");\n>>>> } else {\n>>>> branch_name = \"\";\n>>>> on_what = _(\"Not currently on any branch.\");\n>>>>\n>>>>\n>>>>\n>>>\n>>> No way. That would reduce the information that we give.\n>>\n>> How does it reduce the information we give? Maybe I've missed\n>> something about what \"from\" means here, as opposed to \"at\", but it\n>> seems to me to mean the same thing as \"diverged\" by definition, i.e.\n>> we detached from the branch but we diverged from it.\n>\n> No, \"at\" means we're still at that commit - detached but not diverged.\n> \"from\" means we only started from that commit, but are not at it any more.\n>\n>> Saying \"diverged\"\n>> just makes it clearer, how does it reduce the information we give?\n>\n> I misread your patch on my mobile phone, sorry. I thought you meant to\n> replace both \"at\" and \"from\" by \"diverged from\" because you considered\n> them synonymous.\n>\n> But your patch touches just the\" from\" case and emphasizes the \"diverge\"\n> aspect, which is fine, of course.\n\nAh, that explains the confusion. Yeah saying \"diverged\" for the \"at\"\ncase wouldn't make any sense, there's been no divergence.\n\n>>> 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?\n>>\n>> Right, but I don't see how that's in any way conflicting or mutually\n>> exclusive with saying before hand that we've diverged from the branch.\n>>\n>>> Maybe improve the doc instead?\n>>\n>> Aside from whether my patch makes any sense, the solution to a UX\n>> issue really can't be \"oh this just needs to be documented\". For every\n>> user who's confused by some interface we provide a *tiny* minority of\n>> them go and exhaustively read the docs for an explanation, will just\n>> remain confused.\n>>\n>> I think saying from v.s. at is way too subtle, I for one have been\n>> missing it for years until this thread, that's bad UX, git's also used\n>> by a lot of non-native English speakers who may not at all get the\n>> subtle difference between at and from in this context, or if they do\n>> think the UI is using that subtlety to tell them something.\n>\n> Well, we have to find the right balance between clarity and brevity - an\n> interface that is too chatty is a nightmare. That's why I suggested both\n> doc changes and additional information.\n>\n> What do you think about the ahead/behind info as suggested? That should\n> be more informative both qualitatively (something diverged) and\n> quantitatively (by how much).\n\nI think it's better UX, but worry about placing something like\nrevision walking into \"git status\", that can take a long time. E.g. on\nlinux.git doing:\n\n git checkout origin/master\n git reset --hard v2.6.13\n\nWill yield:\n\n $ time echo \"[ahead $(git rev-list origin/master..HEAD|wc -l),\nbehind $(git rev-list HEAD..origin/master|wc -l)]\"\n [ahead 1, behind 657045]\n real 0m7.859s\n\nThat's admittedly a very pathological case, and could be solved in\npractice by changing the copy so that after e.g. 100 commits we start\nsaying \"over 100 commits ahead...\" or something like that.\n"},{"id":"316817","messageId":"D20C812A0278459095443B62002359A7@PhilipOakley","threadId":"45660","inReplyTo":"61ef36d9-7f25-80d6-5216-554684bd54dd@grubix.eu","subject":"Re: `git status` output is very misleading after a merge on a \"detached HEAD\"","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2017-04-14T16:25:28Z","receivedAt":"2017-04-14T16:32:27Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"- a bit late in providing a comment..\n\nFrom: \"Michael J Gruber\" \n> Ævar Arnfjörð Bjarmason venit, vidit, dixit 12.04.2017 14:18:\n>> On Wed, Apr 12, 2017 at 7:43 AM, Michael J Gruber wrote:\n>>> Am 11. April 2017 22:40:14 MESZ schrieb \"Ævar Arnfjörð Bjarmason\"\n>>> :\n>>>> On Tue, Apr 11, 2017 at 5:13 PM, Enis Bayramoğlu\n>>>>> HEAD detached from origin/master 1 commit ago,\n>>>>\n>>>> In lieu of that, which would need some of the rev-list machinery to be\n>>>> invoked on every git-status, I wonder if just saying \"HEAD detached &\n>>>> diverged from origin/master\" wouldn't be clearer:\n>>>>\n>>>> diff --git a/wt-status.c b/wt-status.c\n>>>> index 308cf3779e..79c8cfd1cf 100644\n>>>> --- a/wt-status.c\n>>>> +++ b/wt-status.c\n>>>> @@ -1542,7 +1542,7 @@ static void wt_longstatus_print(struct wt_status\n>>>> *s)\n>>>> if (state.detached_at)\n>>>> on_what = _(\"HEAD detached at \");\n>>>> else\n>>>> - on_what = _(\"HEAD detached from\n>>>> \");\n>>>> + on_what = _(\"HEAD detached &\n>>>> diverged from \");\n>>>> } else {\n>>>> branch_name = \"\";\n>>>> on_what = _(\"Not currently on any branch.\");\n>>>>\n>>>>\n>>>>\n>>>\n>>> No way. That would reduce the information that we give.\n>>\n>> How does it reduce the information we give? Maybe I've missed\n>> something about what \"from\" means here, as opposed to \"at\", but it\n>> seems to me to mean the same thing as \"diverged\" by definition, i.e.\n>> we detached from the branch but we diverged from it.\n>\n> No, \"at\" means we're still at that commit - detached but not diverged.\n> \"from\" means we only started from that commit, but are not at it any more.\n>\n>> Saying \"diverged\"\n>> just makes it clearer, how does it reduce the information we give?\n>\n> I misread your patch on my mobile phone, sorry. I thought you meant to\n> replace both \"at\" and \"from\" by \"diverged from\" because you considered\n> them synonymous.\n>\n> But your patch touches just the\" from\" case and emphasizes the \"diverge\"\n> aspect, which is fine, of course.\n>\n>>> Note that the difference between from and at is also: are there commits\n>>> that we could lose when we switch away, that is: that git checkout would\n>>> warn us about?\n>>\n>> Right, but I don't see how that's in any way conflicting or mutually\n>> exclusive with saying before hand that we've diverged from the branch.\n>>\n>>> Maybe improve the doc instead?\n\nI think that the doc should highlight the subtelty implied by the at/from\ndistinction. Especially as users may reasonably think that they are detached \nfrom a branch, and not see the distinction.\n\n>>\n>> Aside from whether my patch makes any sense, the solution to a UX\n>> issue really can't be \"oh this just needs to be documented\". For every\n>> user who's confused by some interface we provide a *tiny* minority of\n>> them go and exhaustively read the docs for an explanation, will just\n>> remain confused.\n>>\n>> I think saying from v.s. at is way too subtle, I for one have been\n>> missing it for years until this thread, that's bad UX, git's also used\n>> by a lot of non-native English speakers who may not at all get the\n>> subtle difference between at and from in this context, or if they do\n>> think the UI is using that subtlety to tell them something.\n\nAs a native UK English speaker (living in Scotland), I focus on the verb\n'detached' rather than the at/from distinction. There are many local\ndialects and variants so that is only who are taught English as she is wrote\nwho tend to notice the fine distinctions. (There are many fine Scottish\nwords which are outwith RP English).\n\nAt least if the man page indicated the distinction folks would notice\nsooner - they rarely get to see the distinction side by side in the terminal\nwindow.\n\n>\n> Well, we have to find the right balance between clarity and brevity - an\n> interface that is too chatty is a nightmare. That's why I suggested both\n> doc changes and additional information.\n>\n> What do you think about the ahead/behind info as suggested? That should\n> be more informative both qualitatively (something diverged) and\n> quantitatively (by how much).\n>\n> Michael\n>\n--\nPhilip\n\n"}]}