Re: [PATCH 6/6] Teach core object handling functions about gitlinks

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