Re: `git status` output is very misleading after a merge on a "detached HEAD"
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Apr 12, 2017, 13:30 UTC
- Message-ID
- <CACBZZX4Fkvbqz-ynKwsoj8c4dYZxjjW-OkQbM=SNePL1HAPxkw@mail.gmail.com>
- In-Reply-To
- <61ef36d9-7f25-80d6-5216-554684bd54dd@grubix.eu>
On Wed, Apr 12, 2017 at 3:11 PM, Michael J Gruber <git@grubix.eu> wrote:
Show 49 quoted lines
> Æ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.
Show 26 quoted lines
>>> 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.13Will 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.859sThat'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.