Re: Plumbing for mapping from a remote tracking ref to the remote ref?

From: Tao Klerks <tao@klerks.biz>
Date: Sep 3, 2023, 07:16 UTC
Message-ID: <CAPMMpojUrfSmpgWVh3TTn_uamPCcyHRQf2R3APSpEjsqujNXvA@mail.gmail.com>
In-Reply-To: <xmqqczf5lgk3.fsf@gitster.g>

On Sun, Jun 19, 2022 at 1:04 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 18 quoted lines

>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >>      $ git refmap refs/remotes/somepath/{branch-A,branch-B}
> >>      origin refs/heads/branch-A
> >>      origin refs/heads/branch-B
> >>
> >> IOW, you give name(s) of remote-tracking branches and then you get
> >> the remote and their ref for these?
> >
> > Modulo introducing a new top-level command (a subcommand of `git remote`
> > would make much more sense and make the feature eminently more
> > discoverable), and modulo allowing patterns in the ref to match, I agree.
>
> "git remote" is primarily about "I have this remote---tell me more
> about it", but this query goes in the other direction, and that is
> why I threw a non-existing command to solicit alternatives that are
> potentially better than "git remote".

Thank you for the responses here, and my apologies for not following up (much) earlier.

Given that "git remote" already deals with different types of args (remotes, URLs, remote branches), could it make sense to introduce a dedicated new subcommand, not directly related to "set-branches", eg "map-refs"? I agree with Dscho that keeping it under "git remote" would help with discoverability and avoid clutter in the global namespace: Git already has many top-level commands, the "theme" under which this one fits is definitely "remote stuff", and "git remote" already does a number of substantially-different things all related with *remote configuration*.

In fact that's another way of seeing things: most of "git remote"'s current subcommands are just syntactic sugar over "git config" (the two that operate outside of the config are "set-head" and "update"), and this new one would be config-focused in exactly the same way.

To Junio's question along the lines of "what if someone mapped multiple remote namespaces to a single 'tracking namespace' location in the local repo?" (which I hope is rare - I seem to recall there are at least some operations that warn when this is detected), this ambiguity would be absent in a "git remote" subcommand, as it would take a remote name.

I had also considered some new weird "@{remotemapping}"-style syntax to rev-parse, but here precisely there *would* be no implicit remote context, and so getting more than one answer would be an option, and that doesn't make sense for rev-parse.

Regarding patterns and wildcards, for *my* purpose at least, they don't make much sense: The whole purpose of the exercise is to say "I know the ref I want updated in my repo, I know what remote that it is mapped to or that I want to update it from, I want to know exactly what to put in a "git fetch <remote_name> <remote_ref>..." call, to get that ref updated correctly/consistently for the current repo, without affecting any other refs that this repo has mapped for that remote.

Would something like the following be mutually agreeable?

       $ git remote origin map-ref
refs/remotes/my-favorite-remotes/origin/someref
      refs/heads/someref

       $ git remote origin map-ref
refs/remotes/my-favorite-remotes/origin/someref
refs/remotes/my-favorite-remotes/origin/someotherref
      refs/heads/someref
      refs/heads/someotherref

     $ git remote origin map-ref refs/remotes/someotherpath/someref
      error: the ref "refs/remotes/someotherpath/someref" is not
mapped in any configured refspec of remote "origin".

Thanks, Tao