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

On Wed, Sep 6, 2023 at 12:18 AM Junio C Hamano [off-list ref] wrote:

Tao Klerks [off-list ref] writes:

quoted

...
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,

My apologies: in addition to automatic line wrapping, I also got the
arg order wrong.

Yes, this is what I meant.

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"?

Understanding that it's dangerous to make assumptions about what's
typical, I am positing that the user typically knows what remote
they're working with / looking for stuff in. I would guess that the
set of repos, in the world, that have multiple remotes with different
ref path structures, mapped onto the same remote tracking ref
namespace, is much smaller than the set of repos that have some set of
refs mapped differently to the standard
"refs/heads/*:refs/remotes/originname/*" mapping. My "selfish" intent
was to address the latter, without worrying much about the former.

Isn't that part of
what the user may want to _find_ _out_, instead of required to give
as input?

There's certainly value in enabling them to do so!

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.

No misunderstanding. I was unfortunately more concerned with "fitting
in" with other "git remote" subcommands (which take a remote name)
than making the most useful functionality.

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

This is a much better proposal, from my perspective!

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.