Re: [3/4] What's not in 1.5.2 (new topics)

From: Junio C Hamano <junkio@cox.net>
Date: May 17, 2007, 05:21 UTC
Message-ID: <7v4pmcauu3.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200705170539.11402.andyparkins@gmail.com>

Andy Parkins <andyparkins@gmail.com> writes:

Show 7 quoted lines

> Our in-tree .gitmodules will have the same problem.  I recognise that 
> you've mitigated that with some "confirm with the user, store in the 
> config" hand waving; but that is just hiding the problem: the submodule 
> URL is not something that should be version controlled; it is an 
> all-of-history property; when it changes for revision N it changes for 
> revision N-1, N-2, N-3, etc.  Storing it in .gitmodules implies that 
> it's value in the past has meaning - it doesn't.

I think that depends _WHY_ the URL recorded .gitmodules are updated. It would perfectly be reasonable for release #1 of an appliance project to bind linux 2.4 tree at kernel/ subdirectory while release #2 source to have 2.6 one; they come from two different repository URLs. When you seek the superproject back to release #1, you would still want to fetch from 2.4 upstream if you are updating.

If the URL is changed only because the logically same project was relocated to different hosting service, then what you say is true.

What I was "handwaving" (or "envisioning") was to have something like this in .gitmodules:

	[subproject "kernel/"]
        	URL = git://git.kernel.org/pub/linux-2.4.git

(or 2.6, depending on the revision of the superproject) and per repository configuration would maps this with these two entries:

	[subproject "git://git.kernel.org/pub/linux-2.4.git"]
        	URL = http://www.kernel.org/pub/linux-2.4.git

	[subproject "git://git.kernel.org/pub/linux-2.6.git"]
        	URL = http://www.kernel.org/pub/linux-2.6.git

The intent is

	(1) "kernel/" directory is found to be a gitlink in the
            tree/index; .gitmodules is consulted to find the
            "URL", which is just a handle and the initial hint

	(2) That "initial hint" is used to look up the
            subproject entry from the configuration, to find the
            "real" URL that is used by this repository

> You mentioned yourself that that problem is not confined to the temporal 
> accuracy of .gitmodules, there is spatial accuracy too - there is no 
> guarantee that user A wants to use the same submodule URL as user B.

which hopefully is already answered by the above handwaving ;-).

The case of "relocated to different hosting site" would also be solved by having more than one entries in the configuration file. If a project that used to be hosted at git.or.cz has migrated to git.sf.net, its .gitmodules file from an earlier revision would have URL pointing at git.repo.cz and newer ones would point at git.sf.net. If you started following that project before the migration, you would have:

	[subproject "git://git.or.cz/sub.git"]
        	URL = git://git.or.cz/sub.git

in your .git/config. After the repository migrates to git.sf.net, you would update that existing entry and also add another entry, so that .git/config would have these two entries:

	[subproject "git://git.or.cz/sub.git"]
        	URL = git://git.sf.net/sub.git

	[subproject "git://git.sf.net/sub.git"]
        	URL = git://git.sf.net/sub.git