Re: [PATCH 3/3] completion: fix bugs with slashes in remote names

From: David Mandelberg <david@mandelberg.org>
Date: Mar 7, 2025, 21:38 UTC
Message-ID: <1192682c-b68d-429d-9852-15ab627d711f@mandelberg.org>
In-Reply-To: <xmqqtt84d0dz.fsf@gitster.g>

Op 2025-03-07 om 15:57 schreef Junio C Hamano:

Show 32 quoted lines

> It probably would not mean much either way, and certainly not
> something we should worry about during pre-release feature freeze.
> 
> The "fix" may take quite different shapes.  Remote nick/name may
> still be allowed but the default fetch refspec left by "git clone"
> would start using the refs/remotes/nick-name/ hierarchy instead of
> the refs/remotes/nick/name hierarchy, for example, but as long as
> this round of completion fixes properly read the configuration to
> learn the remote-tracking hierarchy by reading the configured value
> of "remote.nick/name.fetch", such a change would not break the code
> in the completion script at all.  Or remote nick/name may outright
> banned and people are encouraged to use nick-name instead, in which
> case even if the completion code is prepared to accept remote names
> with slashes in it, as long as it still works correctly with remote
> names with no slashes in it, it will keep working in such a future.
> 
> Or the "fix" may be to declare "there is nothing to fix, if people
> want to use
> 
>      [remote "nick/name"] fetch = +refs/heads/*:refs/remotes/nickname/*
>      [remote "nocknyme"] fetch = +refs/heads/*:refs/remotes/nock/nyme/*
> 
> that's their choice, and the completion code would do the right thing
> anyway".
> 
> I didn't read your patches, so the situation may be different and
> with any shape of "fix", or without any "fix", there might still be
> need for further polishing.  But hopefully you got the idea.  For
> this particular patch, there is nothing urgently needed.  Well, we
> are right now in the pre-release feature freeze anyway ;-).
> 
> Thanks.

Thanks for the explanation!

> As a remote name, we still do use "is that a
> file on the filesystem?" to see if it is a local file:// URL
> (i.e. "git fetch github/dseomn" may be fetching from a subdirectory
> two levels down)

Btw, I just tested it, and I think this is an issue for remote names without slashes too:

/tmp/tmp.sVAhhZuEzA$ git init foo
Initialized empty Git repository in /tmp/tmp.sVAhhZuEzA/foo/.git/
/tmp/tmp.sVAhhZuEzA$ cd foo
/tmp/tmp.sVAhhZuEzA/foo$ git init --bare origin
Initialized empty Git repository in /tmp/tmp.sVAhhZuEzA/foo/origin/
/tmp/tmp.sVAhhZuEzA/foo$ git commit --allow-empty -m 'test'
[main (root-commit) 24c92a9] test
/tmp/tmp.sVAhhZuEzA/foo$ git push origin main
Enumerating objects: 2, done.
Counting objects: 100% (2/2), done.
Writing objects: 100% (2/2), 162 bytes | 162.00 KiB/s, done.
Total 2 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
To origin
  * [new branch]      main -> main