Hi, On Thu, 24 May 2007, Sven Verdoolaege wrote: > On Thu, May 24, 2007 at 10:40:52AM -0700, Linus Torvalds wrote: > > > > > > On Thu, 24 May 2007, Junio C Hamano wrote: > > > > > > Why does this have to be out-of-tree and unversioned to begin > > > with? > > > > I _really_ think that the right approach is to > > > > - have the submodules information under version control (and I'd > > personally call it the ".gitmodules" file, but whatever) > > > > This gives you the defaults, and the ability to change them. Remember: > > if you get some "config" information at "git clone" time, you're > > *screwed* if the thing ever changes! > > If you allow an override, then I don't see how having the initial > information in the tree is any better. Isn't that obvious? _Most_ people will _not_ override the information. Plus, it is an easy solution to your problem, without having to touch a lot of real core parts of Git. Simple is beautiful. And less buggy. > When new information gets in from the tree, you're going to ignore it > anyway. No. Not if it is _not_ overridden. > What happens if the URL changes? > You have to modify .gitmodules in _every_ branch you have? Oh yes. Exactly the same as when you have an INSTALL file and the URL of some project changes which your project depends on. That's life. > What if someone is working on his own branch of the superproject > that needs some changes in his own subproject? Uhm. Then you can either just override that URL, _or_ you can branch from the superproject, changing .gitmodules as you wish. > He needs to modify .gitmodules, but when the changes go upstream, > this .gitmodules changes get merged as well. If you change the superproject, that is. And then only if you don't have a to-merge branch. Your problem is not specific to superprojects, and it has been solved already. > Now imagine several developers doing this. > You end up continually having to modify .gitmodules. No, just your config. Once. Ciao, Dscho - 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
