On Tue, 10 Apr 2007, Josef Weidendorfer wrote:

quoted text
> On Tuesday 10 April 2007, Linus Torvalds wrote:
> > ...
> > +	if (resolve_gitlink_ref(ce->name, "HEAD", sha1) < 0)
> > +		return 0;
> > +	return hashcmp(sha1, ce->sha1);
> 
> So this does mean that the SHA1 of a gitlink entry corresponds
> to the commit in the subproject?

Yes.

quoted text
> I wonder if it is not useful to be able to add some attribute(s)
> to a gitlink, i.e. first reference a gitlink object in the superproject,
> which then references the submodule commit, and also holds some
> further attributes. These attributes can not be put into the subproject,
> as it should be independent.

The special "link" object has come up before, and I actually thought I'd 
do it that way first, but there were a few reasons why I didn't:

 - I tend to like "minimal", and the patches I sent out really are pretty 
   minimal, in the sense that they introduce just _one_ new concept, in 
   one place (it's basically a "tree entry" - so it shows up in tree 
   reading and writing, and nowhere else. The index, of course, is the 
   staging area for trees, so the index was also affected, but that was 
   really a very direct result of that "it's a new tree entry" thing).

 - in a "link" object, the only thing that would normally *change* is 
   really just the commit SHA1. Everything else is really pretty static. 
   As such, I decided that it's just a waste of a perfectly fine object to 
   have several thousands of the "link" objects that really only differ in 
   the pointer to the commit.

 - the "static" part, which you might as well have somewhere else, tends 
   to be stuff that you would need to be able to override locally, and as 
   such it does *not* really have a global meaning that is useful 
   historically.

   For example, the things that you'd want to associate with the gitlink 
   are things like "where would I find the repository that the commit is 
   part of" and "what is a description of that submodule" and "what are 
   the relationships between the submodules". These are things that aren't 
   necessarily even totally independent: in CVS, for example, you have 
   module names that are really not submodules themselves, but are really 
   just aliases for *collections* of submodules.

   So a 1:1 link object simply wouldn't make much sense anyway, and you'd 
   want to override those defaults with site-specific ones (maybe there is 
   a "canonical" address for the submodule repository, but if you have a 
   copy of it locally on-site, when you clone, you'd rather use the 
   *local* copy over the standard site, for example).

So all of this just made me say:
 - the tree entry just contains the commit ID of the subproject, and 
   *nothing* else.
 - any incidental data probably isn't 1:1 with tree entries anyway (both 
   over time: you have tree entries being updated with new commit ID's, 
   but the incidental data does *not* change, and over "space": different 
   repositories might want to use their local preferences for incidental 
   rules)
 - which all implies that the extra information should go in a separate 
   file that actually describes the modules.

In fact, it shouldn't be _one_ separate file: it should be at least two, 
since you'd want to have the *defaults* (which get cloned along with the 
superproject) in a revision-controlled file, and then have local *extra* 
information that is local. 

This is exactly the same as the situation with the ".gitignore" file 
(which is revision-controlled and cloned with the respository) and the 
".git/ignore" file (which is repository-local).

I've been thinking either ".gitmodules" (and ".git/modules") or to just 
extend the ".git/config" file parser to *also* parse a version-controlled 
".gitconfig" file, and just describe the modules there. The config file 
really has pretty nice syntax, and I think module descriptions in many 
ways end up similar to remote branch descriptions, so it would fit in 
there, I think.

(But there's nothing that says that the ".gitmodules" file couldn't just 
use the same parser as the git config file, so I don't really strongly 
care either way. I just think it would be nice to be able to say

	[module "kdelibs"]
		dir = kdelibs
		url = git://git.kde.org/kdelibs
		description = "Basic KDE libraries module"

	[module "base"]
		alias = "kdelibs", "kdebase", "kdenetwork"

or whatever. You get the idea..)

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html