Enis Bayramoğlu venit, vidit, dixit 12.04.2017 08:15:
> On Wed, Apr 12, 2017 at 8:43 AM, Michael J Gruber <git@xxxxxxxxx> wrote:
>> Am 11. April 2017 22:40:14 MESZ schrieb "Ævar Arnfjörð Bjarmason" <avarab@xxxxxxxxx>:
>>> On Tue, Apr 11, 2017 at 5:13 PM, Enis Bayramoğlu
>>> <enis@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxx>
>>> 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
>