From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 5E07C1F66F for ; Thu, 12 Nov 2020 18:51:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726584AbgKLSvr (ORCPT ); Thu, 12 Nov 2020 13:51:47 -0500 Received: from cloud.peff.net ([104.130.231.41]:56250 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726554AbgKLSvr (ORCPT ); Thu, 12 Nov 2020 13:51:47 -0500 Received: (qmail 21755 invoked by uid 109); 12 Nov 2020 18:51:47 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Thu, 12 Nov 2020 18:51:47 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 523 invoked by uid 111); 12 Nov 2020 18:51:46 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Thu, 12 Nov 2020 13:51:46 -0500 Authentication-Results: peff.net; auth=none Date: Thu, 12 Nov 2020 13:51:46 -0500 From: Jeff King To: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason Cc: git@vger.kernel.org, Junio C Hamano , Johannes Schindelin , Stefan Beller Subject: Re: How do I "git fetch" with a custom but a default remote? Message-ID: <20201112185146.GD701197@coredump.intra.peff.net> References: <20201111151754.31527-1-avarab@gmail.com> <877dqqhd3s.fsf@evledraar.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <877dqqhd3s.fsf@evledraar.gmail.com> Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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 > and 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=] | --default-remote) [([--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 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