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

[Kévin Le Gouguec]

Tom Tromey <tom@tromey.com> writes:

> Eli> Thanks, but I think we'd appreciate a reproducible recipe for this:
> Eli> how can one create a Git repository which can be used to reproduce
> Eli> this issue?
>
> This worked for me:
>
> $ cd ~/Emacs/trunk
> # This is my Emacs git repository
> $ git checkout --track -b vc-dir-bug master
> branch 'vc-dir-bug' set up to track 'master'.
> Switched to a new branch 'vc-dir-bug'
>
>
> Now invoke vc-dir on that directory.

I can reproduce; IIUC the salient point is setting start-point to a
local revision when calling git checkout, by opposition to
e.g. origin/master.  Continuing off of your recipe:

$ git branch --set-upstream-to origin/master

Then M-x vc-dir works again.

IIUC, to display

  Remote     : https://git.savannah.gnu.org/git/emacs.git

vc-git-dir-extra-headers runs

1. git config branch.vc-dir-bug.remote ⇒ "."
2. (vc-git-repository-url "[… EMACS DIR …]" ".")
    1. git config remote...url ⇒ error

git-config(1) says that branch.<name>.remote is "." when <name> is
tracking a local branch, whereas branch.<name>.merge points to the local
branch 'git pull' will resync with.  Wonder what TRT would be for the
purposes of vc-dir?

(1) Drop the "Remote" header: the current branch is not sync'd with a
remote branch, after all.

(2) Print "Remote: https://git.savannah.gnu.org/git/emacs.git"; by making
vc-git-repository-url fall back to remote.origin.url when remote-name is
".".

(3) Print "Remote: master" by making vc-git-dir-extra-headers fall back
to branch.<name>.merge when .remote is ".".

(4) Make vc-git-dir-extra-headers fall back to
branch.<branch.<name>.merge>.remote.  In our example, that would yield
"Remote: https://git.savannah.gnu.org/git/emacs.git";, but in general
that seems unreliable, since that remote could be "." as well, and
nothing prevents cycles AFAIU.

IMO (3) would be the most robust, though maybe confusing (calling a
local branch "remote"); (2) makes sense as well since
vc-git-repository-url already falls back to remote.origin.url when
remote-name is nil.

(1) sounds trivially "robust" and "not too incorrect", but maybe not the
most helpful.  (4) is under-specified and I'm not convinced it is
possible to make it generally useful.


Hope I've not mis-diagnosed the problem; apologies for the noise if so.