Re: [PATCH 07/16] git-read-tree: take --submodules option

From: Junio C Hamano <junkio@cox.net>
Date: May 19, 2007, 18:20 UTC
Message-ID: <7v4pm8y8tf.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070519130542.GR942MdfPADPa@greensroom.kotnet.org>

Sven Verdoolaege <skimo@kotnet.org> writes:

Show 6 quoted lines

> Does everyone agree that we should fetch (possibly after asking
> for confirmation from the use) _during_ the checkout ?
> I now only fetch submodules during a fetch of the supermodule
> (actually, in my current patch set, I only fetch a submodule
> the first time I see it, but that's a bug), but if there is
> a consensus on this, I can switch to fetching during checkout.

I think fetching of subproject during fetch or clone of superproject would not make much sense. Making it part of superproject checkout would probably be the way we will end up going. The detail of "which part of the checkout" would need to be defined, and I tend to agree with Alex that checkout itself would need to be multi-phased, but I think that is a minor implementation detail we can discuss after how the overall flows should look like.

> As to the key to use to lookup the URL in the config, right
> now I simply use the directory name where it is attached
> (which seems like a useful default to me).

Show 5 quoted lines

> I'm not all that convinced that we should store a default URL
> in history, so AFAICS, the only thing we need to store is a
> mapping between directory names and subproject names.
> It has been suggested to do that in .gitattributes.
> Is that OK for everyone, or do we really need a separate .gitmodules ?

If your (super)repository is _the_ only repository that knows about the aggregation it is doing, I do not think you need anything, as .git/config in the subproject would know where to get updates from. Otherwise, Project wide suggestions need to be there in some machine readable form if you were to allow such superproject distributed, be it in .gitmodules or .gitattributes, don't they?

And frankly, I think .gitattributes is a wrong place to store it, as its semantics is to give attributes to paths that MATCH the glob. You can argue that a pattern in .gitattributes can be written to match only one path, but it still feels conceptually wrong. Something more concrete and exact, like the second level key of .git/config and .gitmodules file format, is preferable.