On Thu, Nov 12, 2020 at 03:19:19PM +0100, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Nov 11 2020, Ævar Arnfjörð Bjarmason wrote:
>
> > In any case, this is one thing that came out of that
> > investigation. The code we're keeping by moving it to git-submodule.sh
> > can also be replaced by some C code we have, but I wanted to leave
> > that to another submission (if I'll get to it), and make this simply a
> > code removal.
>
> I may have missed a way to do $subject, but I don't think it's
> possible.
I'm pretty certain it's not. I've run into this before and looked for a
solution without finding one (in my case I was not scripting, but was
just too lazy to type "origin").
> I came up with this patch:
> [...]
> So it works, but what do we think about this calling convention? Do we
> have any prior art for commands that take positional arguments like
> <remote> and <refspec> where you'd like to use a default for an earlier
> argument to provide a subsequent one?
It seems perfectly reasonable to me. The logic for parsing (that users
must understand) is: if --default-remote is specified, act as if the
default remote was specified as the first argument.
I can't think offhand of a case exactly like this, but certainly options
like "git tag -d" influences how the non-option arguments are parsed.
> To make it more general and consistent we'de probably like a --remote=*
> and --refspec arguments, so the invocation would be:
>
> git fetch ([--remote=]<name> | --default-remote) [([--refspec=]<refspec> | --default-refspec)]
>
> But maybe I'm overthinking it...
If we were starting from scratch, then I think that might have been
nicer, because --default-remote would be implied if there is no
"--remote" option. And then my lazy-to-type:
git fetch topic
would just work. But given that we have the positional <remote>
parameter already, I don't think adding --remote gives much value. And
it raises the question of what "git fetch --remote=foo --remote=bar"
means (I think the answer is last-one-wins).
Slightly orthogonal, but I've occasionally also wished for:
git fetch @{upstream}
or
git fetch @{push}
to grab the latest copy of related branches. Those are a _bit_ funny in
that we usually resolve those names to the local tracking branch. But I
think the semantics are clear (we get to that tracking branch by
applying fetch refspecs to a particular remote).
I mention it only in case it gives you any bright ideas on how the
command-line parsing would work there.
-Peff
