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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 5, 2023, 22:18 UTC
Message-ID: <xmqqpm2wqn6h.fsf@gitster.g>
In-Reply-To: <CAPMMpojUrfSmpgWVh3TTn_uamPCcyHRQf2R3APSpEjsqujNXvA@mail.gmail.com>

Tao Klerks <tao@klerks.biz> writes:

Show 28 quoted lines

> On Sun, Jun 19, 2022 at 1:04 AM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> 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.
> ...
> 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.