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

On Tue, 10 Apr 2007, Josef Weidendorfer wrote:

On Tuesday 10 April 2007, Linus Torvalds wrote:

quoted

...
+	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.

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