GNU bug report logs - #68183
28.3; vc-dir fails when I have a certain branch checked out

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Tom Tromey <tom <at> tromey.com>, 68183 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: bug#68183: 28.3; vc-dir fails when I have a certain branch checked out
Date: Sun, 17 Mar 2024 03:06:36 +0200

On 16/03/2024 19:56, Kévin Le Gouguec wrote:

>> IIUC you're adding the new "Tracking" header to the output? That seems like it should be helpful.
>>
>> Is there a way that we could/should optimize the display? I.e., I guess the most common case will be something like:
>>
>>        Branch     : foo-bar
>>        Tracking   : origin/foo-bar
> 
> Right, the current patch indeed shows this for a common-case clone of
> the Emacs repo:
> 
>      VC backend : Git
>      Working dir: ~/src/emacs/master/
>      Branch     : master
>      Tracking   : origin/master
>      Remote     : https://git.savannah.gnu.org/git/emacs.git
> 
>> which is not bad, but might be less useful than indicating that the current branch does not track anything (and so the next 'git push' should come with '-u'), or tracks a differently named branch. It might be more ergonomic to emphasize "irregular" scenarios and maybe even save on the extra line in the "common" one.
> 
> Good food for thought.
> 
> Re. optimizing the display (which I interpret as reducing redundant
> information): as someone who often works with multiple remotes, seeing
> "Branch: FOO ; Tracking: origin/FOO" is actually useful, so I wouldn't
> want to remove the "tracking" bit unconditionally.  OTOH it could surely
> be condensed to a single line, say
> 
>      Branch     : master (tracking: origin/master)

Yeah, something like this could work. I was imagining pseudo-graphical

     Branch     : master -> origin/master

, but it's good to have words. Maybe drop the last colon...

> Likewise, in the local-tracking-branch case, we could go from
> 
>      Branch:    : vc-dir-bug
>      Tracking   : master
>      Remote     : none (tracking local branch)
> 
> to just
> 
>      Branch:    : vc-dir-bug (tracking: local master)

I would say that the local-tracking scenario is a minority, and so it's 
not as important to optimize, but the above makes sense. But the word 
"local" is very close to "master", while the latter is a special string 
which should probably somehow stand out. So the "unoptimized" version 
might still have its advantages:

      Branch:    : vc-dir-bug (tracking master)
      Remote     : none (local branch)

or

      Branch:    : vc-dir-bug (-> master)
      Remote     : none (local branch)

or

      Branch:    : vc-dir-bug (tracking -> master)
      Remote     : none (local branch)

> Re. emphasizing irregular scenarios, specifically those where 'git push'
> will require '-u': I like the idea, but I am wary of us getting lost in
> the weeds second-guessing Git's intentions.  E.g. even when
> branch.foo.merge and branch.foo.remote are unset, 'git push' can still
> be called without '-u' if push.default is 'current' and
> remote.pushDefault is set (whereas 'git pull' will fail).

Okay, if you're sure. A (no upstream) note might make sense in the above 
scenario too, but I don't have a strong opinion. We could also make a 
user option later, if the new behavior makes sense for most usage habits 
but not all.

>> Just a thought. Not something that needs to be addressed right now. And I might as well be off the mark here.
> 
> I agree it's worth thinking about.  The Right Solution™ would probably
> come with user options to let users fine-tune which details they care
> about?  It would be interesting to survey Git UIs to see how they
> approach this (FWIW I am partial to Magit's presentation, but I have not
> studied how it handles all the corner cases we considered).

Magit, meaning just one line for Head: and another for Merge:?

>>>> * maybe the new header deserves a NEWS entry.
>>> Maybe?
>>
>> It wouldn't hurt. Up to you.
>>
>> Anyway, I think the patch is good to go. Please feel free to install it; whatever cosmetic changes we might like to add could be done later.
> 
> ACK.  I might go a head and install then (after polishing the changelog,
> i.e. re-filling and scrubbing Unicode ellipses) in the spirit of getting
> the original issue fixed; perhaps worth holding off on the NEWS entry
> until we decide how exactly things should look.

I'm okay with that.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.