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

On Thu, 12 Apr 2007, Sam Vilain wrote:

That should actually be something that is fairly natural to handle with the current git submodule design - there's absolutely no problem with having the same subproject showing up in multiple different places in the tree (and each place obviously will have its own commit).

However, it causes some questions at two points:

 - What do you do in the ".gitmodules" file, where you describe the 
   submodule setup?

   This is not so much a _problem_ as a "how do you want to handle it" 
   issue.

   Would people want such a module to show up as "one module" that is just 
   visible in the tree in multiple places? Or do people prefer to think of 
   of it as completely separate modules that just happen to have the same 
   base repository?

   I don't think it's clear that one or the other is the "right way" to 
   see things, and I don't think git really should care. I suspect it's 
   more likely to be a detail that some importer script just has to 
   resolve one way or the other.

   The core git infrastructure needs to be able to have one module show up 
   in multiple places over time anyway, so I don't think there is any real 
   reason not to allow the same module to show up in multiple places even 
   within one single commit.. (Ie it's really mostly about the .gitmodules 
   file *syntax* - but if we use the config file syntax, it's actually 
   very natural to allow multiple entries for the module directory name)

   At the same time, there are reasons why you might want to consider them 
   separate modules too - maybe you want to *descibe* them separately, and 
   maybe one of the copies is used for "legacy support", and you might be 
   in a situation where you want to check out only one of the copies and 
   not the other (and thus describing them as two *different* modules 
   rather than two versions of the *same* module actually makes sense!).

   So I think this is something where we are technically neutral, but 
   where we may have non-technical issues to choose one representation 
   over another (and those issues may have more to do with the *importer* 
   than with any git issues - if importing from Perforce, it probably 
   makes most sense to make the import behave as much as possible the way 
   Perforce did in that case, and I have *no* idea what that is ;)

 - After a conversion is done, and you're no longer talking about a 
   historical archive, but a "going forward" concern, exactly how 
   automatic is subproject movement going to be, and what are downstream 
   developers that pull these things supposed to do when a subproject that 
   they have checked out is moved?

   This is mostly a UI issue. I suspect that the initial answer is: "you 
   may have to un-check-out a subproject, then pull the superproject, and 
   then re-check-it-out to get it in the new location". Simply because 
   it's going to be a lot easier to do than actually having "git pull" 
   notice when subprojects move.

   IOW, that is more of a "just how nice do we want to be to people", and 
   I _think_ the answer is: "as nice as possible, but some things are more 
   important than others, and some things might take longer before they 
   are really pleasant to do" ;)

Hmm?

		Linus