On Tue, 10 Apr 2007, Junio C Hamano wrote: > > But I do not think the .gitmodules thing needs that. If we have > conflicting (or non-conflicting for that matter) submodule > moves, that's a _MAJOR_ project re-organization, and I do not > think we would even want to automatically descend into > submodules for merging or checking-out when we have such a > situation in the higher level project. 100% agreed. Also, note that while the ".gitmodules" (or whatever) file will be required to do things like "git pull", the basic tree-level logic that I sent out obviously doesn't need/use .gitmodules at all. So there's a very real issue where a repository with submodules still "works", even with a .gitmodules file that is totally scrogged and doesn't have the right information (yet), it's just that it may simply not be able to do all the operations because it cannot figure out where to pull missing subproject data from etc.. So there is no reason to believe that we need to magically and automatically resolve conflicts - if conflicts happen, functionality is reduced, but it's not reduced so much that you cannot use the tree and try to resolve them (which is important, btw, since often before you commit your fix for the conflicts you'd want to *test* that fix, so we definitely don't want these kinds of files to be so central that it gets hard to get normal work done without them). It really boils down to the same design issue: the way I think submodules should work is that they are very loosely coupled with the supermodule. The fact that the ".gitmodules" file isn't *that* critical comes largely from that loose coupling. Linus - 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