On Thu, May 17, 2007 at 06:10:02PM +0200, Petr Baudis wrote: > But, did you read what you actually quoted? Because I can only repeat my > argument in the face of (1), and you didn't seem to dispute any part of > it at all. You said: > Because kernel/ can get removed, moved around, or point at entirely > *different* projects over time and branches - kernel/ can switch from > linux-2.4 to linux-2.6, libc/ can switch between glibc and uClibc, ... which I took to mean that we must be able to track changes to the URL which is pointed to by the kernel/ submodule, and therefore this configuration must be in a tracked file. Which is _precisely_ what I advocated: it goes in a .gitmodules (or .gitconfig) file in the tracked directory. This is counter to what Alex says, which is that one should simply pull the config down during clone time and never change it. However, I think we _must_ have an override mechanism, since I don't necessarily use the same URLs that you do. I propose that such overrides should go into the local repo config. The only difference between what I have proposed and what Junio mentioned is that I would base the config override key on the directory name, not the URL. This means that if upstream changes their pointer to the URL, yours will change with it _unless you have an override_. With Junio's, their change of URL will override your change (since the key will no longer match your config). How do you propose to handle overrides? > "kernel/" has _no_ meaning. Only a (treeid,"kernel/") pair has meaning, > nothing less - a particular tree contains a submodule in given subtree. > Different trees can have different submodules in different subtrees. Right. In my proposal (unlike Alex's), it _is_ tied to the tree, since that tree has a particular .gitmodules. But I also think you should be able to override the submodule URL for kernel/ _for all time_ if you want. -Peff - 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
