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

[Dmitry Gutov]

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.