Re: [RFC] Third round of support for cloning submodules

[Martin Waitz <tali@admingilde.org>]

[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]

hoi :)

On Mon, May 21, 2007 at 10:54:19AM +0200, Sven Verdoolaege wrote:
> On Mon, May 21, 2007 at 12:52:53AM +0200, Martin Waitz wrote:
> > That leads to submodules which store their objects within the
> > supermodule .git directory,
> 
> My code clones submodules in .git/submodules/<submodule>, so
> that could be a good default.

good.

> > which would automatically obsolete the
> > need to specify explicit submodule URLs.
> 
> Absolutely not.  The subproject will likely have a life of its own.
> If you export it on the same machine, then why would you have two
> different URLs for the same project?
> Also, the subproject will typically not even be on the same site,
> so you _have_ to be able to specify a submodule URL.
> (I noticed that I forgot the "git://" protocol; I'll add that in
> the next round.)

Typically, you have to keep it on the same site because you have
some local adaptions which are only ment to be included within the
superproject.  Think about distributions which seldomly use upstream
software completely unmodified.
Being able to configure it for other URLs is nice but by default it
should work without.

> > So back to your code: I don't like absolute URLs in the cloneable part
> > of the repository.  We should try to stay with relative ones which
> > can stay the same everywhere.
> 
> The problem with relative paths is that you don't know if the
> URL the user gave you points to the working directory or the
> git directory of the project, but I guess I can let dump-config
> tell you where it found the config file.

We have already solved that in clone & fetch so I don't think this is a
real problem.

-- 
Martin Waitz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]