From: "Nigel Magnay" <nigel.magnay@gmail.com>
To: "Jakub Narebski" <jnareb@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Petr Baudis" <pasky@suse.cz>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: [PATCH] Teach git submodule update to use distributed repositories
Date: Fri, 18 Jul 2008 10:18:27 +0100 [thread overview]
Message-ID: <320075ff0807180218k7cfd4b07l67a1c82af0d61653@mail.gmail.com> (raw)
In-Reply-To: <200807181107.18098.jnareb@gmail.com>
On Fri, Jul 18, 2008 at 10:07 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano wrote:
>
>> [...] It is understandable that you would
>> want to script something that recurses into the submodules that you have
>> checked out (or submodules that Fred wants you to look at), do the
>> equivalent of "git fetch ../fred" you did at the toplevel to automate that
>> step, but I very much agree with Pasky here in that it feels very wrong to
>> hijack "submodule update" for it.
>
> There were two proposals how to deal with fetching all submodules:
> (a) git-submodule recursing into submodules, IIRC even with some
> implementation (b) new "git submodule fetch" command.
>
Yes - I think there's a few more options and possible combinations
a. git submodule update having <repository> <refspec> to recurse into
submodules (a)(original patch)
b. git submodule fetch
c. git fetch --submodules
d. git fetch (automatically recurse if there are submodules)
e. git fetch (automatically recurse if there is some setting in .git/config)
I started at (a) and agree that it's a bad choice.
Any of b-e would work for me.
My (personal) preferences would be for d/e, then c, then b - but -
that's based on my belief that submodules are a pretty fundamental
thing and having a separate UI is bad.
next prev parent reply other threads:[~2008-07-18 9:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-17 12:08 [PATCH] Teach git submodule update to use distributed repositories Nigel Magnay
2008-07-17 12:13 ` Johannes Schindelin
[not found] ` <320075ff0807170520r200e546ejbad2ed103bd65f82@mail.gmail.com>
2008-07-17 12:21 ` Nigel Magnay
2008-07-17 12:58 ` Johannes Schindelin
2008-07-17 14:03 ` Nigel Magnay
2008-07-17 14:16 ` Johannes Schindelin
2008-07-17 15:07 ` Nigel Magnay
2008-07-17 18:22 ` Petr Baudis
2008-07-18 8:11 ` Nigel Magnay
2008-07-18 8:45 ` Jakub Narebski
2008-07-18 9:00 ` Junio C Hamano
2008-07-18 9:07 ` Jakub Narebski
2008-07-18 9:18 ` Nigel Magnay [this message]
2008-07-18 9:16 ` Petr Baudis
2008-07-18 9:36 ` Nigel Magnay
2008-07-18 10:00 ` Petr Baudis
2008-07-18 11:20 ` Nigel Magnay
2008-07-18 14:43 ` Petr Baudis
2008-07-18 15:09 ` Nigel Magnay
2008-07-18 15:49 ` Petr Baudis
2008-07-18 22:38 ` Mark Levedahl
2008-07-21 10:59 ` Nigel Magnay
2008-07-17 14:38 ` Petr Baudis
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=320075ff0807180218k7cfd4b07l67a1c82af0d61653@mail.gmail.com \
--to=nigel.magnay@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
--cc=pasky@suse.cz \
/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.
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 NNTP newsgroup(s).