Re: [PATCH] Teach git submodule update to use distributed repositories

From: Nigel Magnay <nigel.magnay@gmail.com>
Date: Jul 18, 2008, 11:20 UTC
Message-ID: <320075ff0807180420k4b28c317mc026713b22c44839@mail.gmail.com>
In-Reply-To: <20080718100048.GN10151@machine.or.cz>

On Fri, Jul 18, 2008 at 11:00 AM, Petr Baudis <pasky@suse.cz> wrote:

Show 14 quoted lines

> On Fri, Jul 18, 2008 at 10:36:51AM +0100, Nigel Magnay wrote:
>> 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.
>
> Wait, I'm lost again - _additional_ problem? How does it differ from the
> _original_ problem, how does it differ from what you're explaining below
> and how does what you're explaining below differ from the original
> problem?
>

In addition to the problem of needing to execute multiple commands and edit files to acheive what is a rather simple usecase, there is the additional problem of discovering (for a third party) a url for where their submodules are stored.

> Or are we talking exclusively about what I summed up above now?
>

In this part of the thread. The first part seems to have broad agreement that a command could be added / modified, but not yet what it should look like.

Show 11 quoted lines

>> 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
>
> I think you mean git pull --submodules fred. Well, actually, you want to
> pull the main repository, then submodule update (_not_ pull in the
> submodules). See? This is part of the "semantic swamp" I mentioned
> before.

Ah - I understand. You're saying "you can't pull submodules when you pull the supermodule, because you don't know which submodules might be needed until you also merge / checkout the desired revision" ?

Ack.

Show 9 quoted lines

>
> I think it should be somehow part of the _main_ project's fred branch
> that in this branch, the subprojects should be fetched from a different
> location; thus, you would still do
>
>        $ git remote add fred git://fredcomputer/superproject/.git
>        $ git pull fred
>        $ git submodule update
>

Yes, that makes sense.

Show 9 quoted lines

> where either the submodule update takes the info from fred's adjusted
> .gitmodules, or it is an implicit part of the branch as in fred tells
> you to run the update command with some extra arguments.
>
> However, I still believe the information should primarily stem from the
> main repository; consider e.g. if you do not have some of the submodules
> checked out when you switch to fred, then figure out that in fred's
> branch, you really do want them checked out.
>

Yes. Referring to your earlier mail, I'm now preferring "(4) Something else that I'm not realizing." ;-)

Hm. It feels like each person could have some 'local' info in their .gitmodules, and rules around merging; but I'm not sure of exactly what, or how.