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

> 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.