From: Nicolas Pitre <nico@cam.org>
Date: Thu, 17 May 2007 13:45:24 GMT
Subject: Re: [3/4] What's not in 1.5.2 (new topics)
Message-ID: <alpine.LFD.0.99.0705170941590.24220@xanadu.home>
In-Reply-To: <7v4pmcauu3.fsf@assigned-by-dhcp.cox.net>

On Wed, 16 May 2007, Junio C Hamano wrote:

> Andy Parkins <andyparkins@gmail.com> writes:
> 
> > 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.

I don't know if the above example should make sense.  In practice that 
would mean you'll have to _replace_ the repo within the submodule 
directory which is quite different from merely checking out a different 
version of the same repository.


Nicolas