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

Tao Klerks [off-list ref] writes:

On Sun, Jun 19, 2022 at 1:04 AM Junio C Hamano [off-list ref] wrote:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

quoted

     $ 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.
...
Would something like the following be mutually agreeable?

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

With strainge line wrapping, I cannot quite tell what is the input
and what is the output, but if you meant that the part up to the
long-ish refname in the refs/remotes is the command line, and map-ref
is the new subcommand name in the "git remote" command, i.e.

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

is the input, to which the output 

    refs/heads/someref

is given, I am not sure what its value is.  First of all, the user
is giving a ref in a hierarchy that is usually used for the remote
whose name is "my-favorite-remotes".  What made this user _know_
that the remote reference belongs to "origin"?  Isn't that part of
what the user may want to _find_ _out_, instead of required to give
as input?

So, no, I do not think it is agreeable at least not from this end,
but I may be misunderstanding what you meant to present as your
design.

I would understand if it were more like

    $ git remote refmap refs/remotes/somepath/{branch-A,branch-B}
    origin:refs/heads/branch-A refs/remotes/somepath/branch-A
    origin:refs/heads/branch-B refs/remotes/somepath/branch-B

that is,

 (1) the new subcommand (refmap) takes one or more refs from the
     command line; they typically are in the refs/remotes hiearchy
     and each asks which remote's which ref needs to be fetched to
     update the ref.  Note that the user does *not* need to know
     which remote the refs will be updated from.

 (2) the subcommand goes through the "remote.*.fetch" configuration
     items (and its older equivalents in .git/remotes, whose support
     should come free if you used remote.c API properly) to find
     what ref from what remote is fetched to update the refs given
     from the command line.

 (3) the output is "<remote>:<ref-at-remote> <our-remote-tracking-branch>"
     one line at a time.

Note that this format allows the "two remotes can both update the
same remote tracking branches we have" arrangement.