* `git status` output is very misleading after a merge on a "detached HEAD" @ 2017-04-11 8:57 Enis Bayramoğlu 2017-04-11 14:55 ` Michael J Gruber 0 siblings, 1 reply; 11+ messages in thread From: Enis Bayramoğlu @ 2017-04-11 8:57 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: `git status` output is very misleading after a merge on a "detached HEAD" 2017-04-11 8:57 `git status` output is very misleading after a merge on a "detached HEAD" Enis Bayramoğlu @ 2017-04-11 14:55 ` Michael J Gruber 2017-04-11 15:13 ` Enis Bayramoğlu 0 siblings, 1 reply; 11+ messages in thread From: Michael J Gruber @ 2017-04-11 14:55 UTC (permalink / raw) To: Enis Bayramoğlu, git 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: `git status` output is very misleading after a merge on a "detached HEAD" 2017-04-11 14:55 ` Michael J Gruber @ 2017-04-11 15:13 ` Enis Bayramoğlu 2017-04-11 20:40 ` Ævar Arnfjörð Bjarmason 0 siblings, 1 reply; 11+ messages in thread From: Enis Bayramoğlu @ 2017-04-11 15:13 UTC (permalink / raw) To: Michael J Gruber; +Cc: git > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: `git status` output is very misleading after a merge on a "detached HEAD" 2017-04-11 15:13 ` Enis Bayramoğlu @ 2017-04-11 20:40 ` Ævar Arnfjörð Bjarmason 2017-04-12 5:43 ` Michael J Gruber 0 siblings, 1 reply; 11+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2017-04-11 20:40 UTC (permalink / raw) To: Enis Bayramoğlu; +Cc: Michael J Gruber, Git Mailing List 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: `git status` output is very misleading after a merge on a "detached HEAD" 2017-04-11 20:40 ` Ævar Arnfjörð Bjarmason @ 2017-04-12 5:43 ` Michael J Gruber 2017-04-12 6:15 ` Enis Bayramoğlu 2017-04-12 12:18 ` Ævar Arnfjörð Bjarmason 0 siblings, 2 replies; 11+ messages in thread From: Michael J Gruber @ 2017-04-12 5:43 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason, Enis Bayramoğlu Cc: Git Mailing List 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: `git status` output is very misleading after a merge on a "detached HEAD" 2017-04-12 5:43 ` Michael J Gruber @ 2017-04-12 6:15 ` Enis Bayramoğlu 2017-04-12 11:36 ` Michael J Gruber 2017-04-12 12:18 ` Ævar Arnfjörð Bjarmason 1 sibling, 1 reply; 11+ messages in thread From: Enis Bayramoğlu @ 2017-04-12 6:15 UTC (permalink / raw) To: Michael J Gruber; +Cc: Ævar Arnfjörð Bjarmason, Git Mailing List 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: `git status` output is very misleading after a merge on a "detached HEAD" 2017-04-12 6:15 ` Enis Bayramoğlu @ 2017-04-12 11:36 ` Michael J Gruber 0 siblings, 0 replies; 11+ messages in thread From: Michael J Gruber @ 2017-04-12 11:36 UTC (permalink / raw) To: Enis Bayramoğlu Cc: Ævar Arnfjörð Bjarmason, Git Mailing List 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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: `git status` output is very misleading after a merge on a "detached HEAD" 2017-04-12 5:43 ` Michael J Gruber 2017-04-12 6:15 ` Enis Bayramoğlu @ 2017-04-12 12:18 ` Ævar Arnfjörð Bjarmason 2017-04-12 13:11 ` Michael J Gruber 1 sibling, 1 reply; 11+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2017-04-12 12:18 UTC (permalink / raw) To: Michael J Gruber; +Cc: Enis Bayramoğlu, Git Mailing List 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: `git status` output is very misleading after a merge on a "detached HEAD" 2017-04-12 12:18 ` Ævar Arnfjörð Bjarmason @ 2017-04-12 13:11 ` Michael J Gruber 2017-04-12 13:30 ` Ævar Arnfjörð Bjarmason 2017-04-14 16:25 ` Philip Oakley 0 siblings, 2 replies; 11+ messages in thread From: Michael J Gruber @ 2017-04-12 13:11 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: Enis Bayramoğlu, Git Mailing List Æ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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: `git status` output is very misleading after a merge on a "detached HEAD" 2017-04-12 13:11 ` Michael J Gruber @ 2017-04-12 13:30 ` Ævar Arnfjörð Bjarmason 2017-04-14 16:25 ` Philip Oakley 1 sibling, 0 replies; 11+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2017-04-12 13:30 UTC (permalink / raw) To: Michael J Gruber; +Cc: Enis Bayramoğlu, Git Mailing List 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: `git status` output is very misleading after a merge on a "detached HEAD" 2017-04-12 13:11 ` Michael J Gruber 2017-04-12 13:30 ` Ævar Arnfjörð Bjarmason @ 2017-04-14 16:25 ` Philip Oakley 1 sibling, 0 replies; 11+ messages in thread From: Philip Oakley @ 2017-04-14 16:25 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason, Michael J Gruber Cc: Enis Bayramoğlu, Git Mailing List - 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-04-14 16:32 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-11 8:57 `git status` output is very misleading after a merge on a "detached HEAD" Enis Bayramoğlu 2017-04-11 14:55 ` Michael J Gruber 2017-04-11 15:13 ` Enis Bayramoğlu 2017-04-11 20:40 ` Ævar Arnfjörð Bjarmason 2017-04-12 5:43 ` Michael J Gruber 2017-04-12 6:15 ` Enis Bayramoğlu 2017-04-12 11:36 ` Michael J Gruber 2017-04-12 12:18 ` Ævar Arnfjörð Bjarmason 2017-04-12 13:11 ` Michael J Gruber 2017-04-12 13:30 ` Ævar Arnfjörð Bjarmason 2017-04-14 16:25 ` Philip Oakley
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).