From: "Nigel Magnay" <nigel.magnay@gmail.com>
To: "Petr Baudis" <pasky@suse.cz>
Cc: "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:36:51 +0100 [thread overview]
Message-ID: <320075ff0807180236u4e7f5f9bm81b702d14c052de8@mail.gmail.com> (raw)
In-Reply-To: <20080718091608.GL10151@machine.or.cz>
On Fri, Jul 18, 2008 at 10:16 AM, Petr Baudis <pasky@suse.cz> wrote:
> snip
>
> "How do we mass-supply custom submodule URLs when publishing the
> customized main repository at a custom location too?"
>
Yes - that is an additional problem.
If I may expand the usecase just so it's clear (and to check we're
talkiing the same language)
I do something like
$ git remote add fred git://fredcomputer/superproject/.git
$ git fetch --submodules fred
And when the recursive fetching enters a submodule, it is trying
itself to do something like
$ git fetch fred
At which point
1) the submodule also has a remote specified for fred. In which case
it can continue
2) the submodule doesn't have remote specified for fred. How to solve
this case? (I.E how does 'my' git 'discover' where fred's git
repositories are for the submodules?)
a) By getting some information from fred, either in *Fred's*
superproject .git/config (or some other readable file)
b) By reading some information out of the superproject .gitmodules
that has been fetched from fred
c) By calculating a relative URL based on the supposition that fred
has working copies laid out in the filesystem.
I was tentatively suggesing (c), with a backup of (a) for the minority
cases where you weren't pulling from a person but from a mirror or
something. Having the client edit config files just feels like a hack
to me, regardless of whether scripts are enabled to do it.
next prev parent reply other threads:[~2008-07-18 9:37 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
2008-07-18 9:16 ` Petr Baudis
2008-07-18 9:36 ` Nigel Magnay [this message]
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=320075ff0807180236u4e7f5f9bm81b702d14c052de8@mail.gmail.com \
--to=nigel.magnay@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--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).