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

[Junio C Hamano <junkio@cox.net>]

Alex Riesen <raa.lkml@gmail.com> writes:

> Junio C Hamano, Thu, May 17, 2007 07:21:40 +0200:
>> 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
>
> So, assuming .gitmodules is versioned (afaics, it is), it would mean
> that after a some unlucky git-pull, where someone changed the upstream
> .gitmodules ("linux-2.4" for whatever reason is changed to just
> "linux"). And suddenly all such local configuration is useless:

See below.

>> (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"]
>
> isn't there a typo somewhere around "2.6"?
>
>>         	URL = http://www.kernel.org/pub/linux-2.6.git
>
> because there is no URL to map from.

The basic idea is that you keep mappings for all the URLs that
appear in versions of .gitmodules in the history you are
interested in checking out.  If the upstream switches from 2.4
based one to 2.6 based one, .gitmodules would contain a new URL,
which is not yet known to your configuration.  Then either the
UI would ask, with the default hint in the .gitmodules you just
pulled, refuse and have you manually add it to your config after
confirming, or just take the default (iow "trust the upstream").

So, no, it is not a reason to drop older mappings when your tip
was updated by a pull.  It should still be possible to checkout
older version that depend on the older 2.4 based subproject.

> why can't I just have _repo_ configuration:
>
>  	[subproject "kernel/"]
>          	URL = http://www.kernel.org/pub/linux-2.6.git
> ?
> It can be first-time cloned from the upstream, but it stays after
> people change it to suit their systems. They can depend on it not to
> be broken by upstream.

But that is a wrong thing to do when you are forking from the
release #1 of the appliance project, which wanted to have 2.4
based on at that path.