On Wed, Sep 6, 2023 at 12:18 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Tao Klerks <tao@xxxxxxxxxx> writes:
>
> > ...
> > 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.
>
