From: Jeff King <peff@peff.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Johannes Schindelin <johannes.schindelin@gmx.de>,
Stefan Beller <stefanbeller@gmail.com>
Subject: Re: How do I "git fetch" with a custom <refspec> but a default remote?
Date: Thu, 12 Nov 2020 13:51:46 -0500 [thread overview]
Message-ID: <20201112185146.GD701197@coredump.intra.peff.net> (raw)
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
next prev parent reply other threads:[~2020-11-12 18:51 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-11 13:47 [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good Johannes Schindelin
2017-05-11 13:47 ` [PATCH 01/11] git-parse-remote: fix highly misleading man page Johannes Schindelin
2017-05-11 17:21 ` Stefan Beller
2017-05-11 19:14 ` Johannes Schindelin
2020-11-11 15:17 ` [PATCH 0/5] Remove now-unused git-parse-remote Ævar Arnfjörð Bjarmason
2020-11-11 17:37 ` Jeff King
2020-11-11 19:29 ` Junio C Hamano
2020-11-12 14:09 ` Ævar Arnfjörð Bjarmason
2020-11-12 18:42 ` Jeff King
2020-11-12 14:19 ` How do I "git fetch" with a custom <refspec> but a default remote? Ævar Arnfjörð Bjarmason
2020-11-12 18:51 ` Jeff King [this message]
2020-11-12 19:26 ` Chris Torek
2020-11-12 20:48 ` Jeff King
2020-11-12 21:22 ` Junio C Hamano
2020-11-14 12:12 ` Ævar Arnfjörð Bjarmason
2020-11-11 15:17 ` [PATCH 1/5] parse-remote: remove unused GIT_DIR variable Ævar Arnfjörð Bjarmason
2020-11-11 15:17 ` [PATCH 2/5] parse-remote: remove long-dead rebase code Ævar Arnfjörð Bjarmason
2020-11-11 15:17 ` [PATCH 3/5] parse-remote: remove long-dead git-pull.sh code Ævar Arnfjörð Bjarmason
2020-11-11 15:17 ` [PATCH 4/5] parse-remote: move used code to git-submodule.sh Ævar Arnfjörð Bjarmason
2020-11-11 15:17 ` [PATCH 5/5] parse-remote: remove this now-unused library Ævar Arnfjörð Bjarmason
2020-11-11 16:33 ` Junio C Hamano
2020-11-12 20:31 ` [PATCH v2 0/2] Retire git-parse-remote Junio C Hamano
2020-11-12 20:31 ` [PATCH v2 1/2] parse-remote: move used code to git-submodule.sh Junio C Hamano
2020-11-12 20:31 ` [PATCH v2 2/2] parse-remote: remove this now-unused library Junio C Hamano
2020-11-12 20:49 ` [PATCH v2 0/2] Retire git-parse-remote Jeff King
2020-11-12 21:25 ` Junio C Hamano
2020-11-13 9:42 ` Ævar Arnfjörð Bjarmason
2020-11-14 12:21 ` [PATCH v3 0/3] submodule sh->C & retire parse-remote Ævar Arnfjörð Bjarmason
2020-11-14 12:21 ` [PATCH v3 1/3] submodule: use "fetch" logic instead of custom remote discovery Ævar Arnfjörð Bjarmason
2020-11-16 21:13 ` Junio C Hamano
2020-11-14 12:21 ` [PATCH v3 2/3] submodule: remove sh function in favor of helper Ævar Arnfjörð Bjarmason
2020-11-14 12:21 ` [PATCH v3 3/3] parse-remote: remove this now-unused library Ævar Arnfjörð Bjarmason
2020-11-16 21:19 ` Junio C Hamano
2020-11-17 14:24 ` Ævar Arnfjörð Bjarmason
2017-05-11 13:47 ` [PATCH 02/11] Documentation: really deprecate .git/remotes/ and .git/branches/ Johannes Schindelin
2017-05-11 13:47 ` [PATCH 03/11] remote: warn loud and clear when .git/branches/ is *still* used Johannes Schindelin
2017-05-11 13:47 ` [PATCH 04/11] remote: warn loud and clear when .git/remotes/ " Johannes Schindelin
2017-05-11 13:47 ` [PATCH 05/11] Revert "Revert "Don't create the $GIT_DIR/branches directory on init"" Johannes Schindelin
2017-05-11 17:26 ` Stefan Beller
2017-05-11 13:47 ` [PATCH 06/11] PREVIEW: t5510: convert .git/remotes/ test to use a regular remote Johannes Schindelin
2017-05-11 13:47 ` [PATCH 07/11] PREVIEW: t5516: stop testing .git/branches/ functionality Johannes Schindelin
2017-05-11 13:47 ` [PATCH 08/11] PREVIEW: remote: remove support for migrating ancient remotes Johannes Schindelin
2017-05-11 13:48 ` [PATCH 09/11] PREVIEW: t5515: remove .git/remotes/ and .git/branches/ tests Johannes Schindelin
2017-05-11 13:48 ` [PATCH 10/11] PREVIEW: t0060: stop testing support for .git/remotes/ and .git/branches/ Johannes Schindelin
2017-05-11 13:48 ` [PATCH 11/11] PREVIEW: remove " Johannes Schindelin
2017-05-11 18:19 ` Stefan Beller
2017-05-11 19:19 ` Johannes Schindelin
2017-05-12 1:14 ` [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good Junio C Hamano
2017-05-12 10:18 ` Johannes Schindelin
2017-05-16 0:37 ` Junio C Hamano
2017-05-16 8:05 ` Ævar Arnfjörð Bjarmason
2017-05-16 9:06 ` Junio C Hamano
2017-05-16 10:02 ` Ævar Arnfjörð Bjarmason
2017-05-17 0:51 ` Junio C Hamano
2017-05-12 12:00 ` Junio C Hamano
2017-05-12 14:19 ` Johannes Schindelin
2017-05-12 17:38 ` Jonathan Nieder
2017-05-13 10:13 ` Junio C Hamano
2017-05-12 21:11 ` Junio C Hamano
2017-05-15 8:42 ` Johannes Schindelin
2017-05-12 9:11 ` Jeff King
2017-05-12 11:09 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201112185146.GD701197@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
--cc=stefanbeller@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).