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