On Tue, Apr 8, 2008 at 11:03 PM, Roman Shaposhnik <rvs@xxxxxxx> wrote: > On Apr 8, 2008, at 2:01 PM, Avery Pennarun wrote: > > The way to understand git-submodule's operation is in terms of what it > > actually does. Roughly speaking, git-submodule-add puts things into > > .gitmodules and .git/config; > > I could be mistaken, but I don't think "git submodule add" does anything > to the .git/config. In fact, how settings migrate between .gitmodules > and .git/config has been a long standing source of slight confusion > for me. > > Please correct me if I'm wrong, but it seems that the only reason > for the file .gitmodules to be there at all is because it can be > revved through commits, just as any file under Git's control. > .git/config doesn't have such a property. Other than that, it is not > really needed, right? You have the last paragraph right, but I think the first paragraph wrong :) .gitmodules doesn't do anything unless git-submodule reads it, which it does in git-submodule-init and git-submodule-add. (You know git-submodule-add is screwing with .git/config because you don't need to call git-submodule-init when you use it.) git-submodule-update, AFAICT, just reads .git/config. > Speaking of complications, it took me awhile to realize that 90% > of the Submodule magic seems to be based on the secret ability of > tree objects to hold references not only to blobs and trees but > also to *commits*: Indeed, this is the majority of the coolness right there. The rest of the screwiness with .gitmodules and so on is really just to support fetching the objects for the submodules from repos than the primary supermodule one. Also, git-checkout seems to explicitly *not* checkout refs to commits by itself; you have to call git-submodule-update for that. This is probably because git-checkout wouldn't know what to do if the submodule were dirty (ie. the sub-checkout couldn't complete because files had been changed but not checked in). This is useful in a not-destroying-my-data way, but the behaviour isn't too obvious or coherent. > That's exactly what makes me doubtful about .gitmodules being the > best place for storing the url, but then again, I don't have any > better ideas. :-( Yet ;-) There's definitely no better place; .git/config isn't versioned, and URLs don't belong in the tree objects themselves, which are otherwise location-neutral and transport-neutral. In my own use case, I think having all the objects from the supermodule *and* submodules all be in the same repo is what I want. This kind of obviates the need for .gitmodules entirely, if git-checkout and friends will do the right thing. I think I'll submit some patches eventually once I have this figured out properly. Have fun, Avery -- 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
