On Wed, 16 May 2007, Junio C Hamano wrote: > Andy Parkins <andyparkins@xxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
