On Tue, 10 Apr 2007, Josef Weidendorfer wrote: > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html