Re: [PATCH 07/16] git-read-tree: take --submodules option

Jan Hudec [off-list ref] writes:

It would also solve (rare) case when for some reason the same subproject
should be checked out twice (different revisions).

I have a feeling that you are equating two subprojects that
happens to have the same upstream URL the same, and if that is
the case I think that is a mistake.

If you were doing an efficient cgi script that renders history
of git managed projects, binding git as its subproject, and that
system can be built with either 'maint' (i.e. 1.5.2 series) or
'master' (i.e. ultrastable WIP towards 1.5.3), even though they
both might come from git://git.kernel.org/pub/scm/git/git.git/,
I think they should be registered as two separate logical
subprojects.

The .gitmodules file might have:

	[module "git-maint"]
        	path = git-stale/
        	url = git://git.kernel.org/pub/scm/git/git.git/
                ;; branch = maint

	[module "git-master"]
        	path = git-stable/
        	url = git://git.kernel.org/pub/scm/git/git.git/
                ;; branch = master

and two paths (git-stale/ and git-stable/) in the superproject
tree would have commit object names from the named branches.

Junio C Hamano wrote:

If you were doing an efficient cgi script that renders history
of git managed projects, binding git as its subproject, and that
system can be built with either 'maint' (i.e. 1.5.2 series) or
'master' (i.e. ultrastable WIP towards 1.5.3), even though they
both might come from git://git.kernel.org/pub/scm/git/git.git/,
I think they should be registered as two separate logical
subprojects.
  

I agree strongly with this, and it's another good reason that we have to 
be able to use something other than the URL as the key to look up a 
subproject's repository location. If you use the URL it is impossible to 
differentiate the two subprojects in this case.

-Steve