From: Jeff King <peff@peff.net>
Date: Thu, 12 Nov 2020 18:51:46 GMT
Subject: Re: How do I "git fetch" with a custom <refspec> but a default remote?
Message-ID: <20201112185146.GD701197@coredump.intra.peff.net>
In-Reply-To: <877dqqhd3s.fsf@evledraar.gmail.com>

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