Linus Torvalds wrote: > So the thing is (and this was pretty much the original basis for > .gitmodules) that pretty much *all* of the above fields are quite > possibly site-specific, rather than globally stable. > > So I actually conceptually like (and liked) the notion of a link > object, but I just don't think it is necessarily practically useful, > exactly because different installations of the *same* supermodule > might well want to have different setups wrt these submodule fields. > > My gut feel is that yes, .gitmodules was always a bit of a hack, but > it's a *working* hack, and it does have advantages exactly because > it's more fluid than an actual git object (which by definition has to > be set 100% in stone). If there are things you feel it does wrong > (like the "git add" bug that is being discussed elsewhere), I wonder > if it's not best to at least try to fix/extend them in the current > model. The features you seem to be after (ie that whole > floating/refname thing) don't seem fundamentally antithetical to the > current model (a "commit" SHA1 of all zeroes for floating, with a new > refname field in .submodules? I dunno).. Let's compare the two alternatives: .gitmodules versus link object. If I want my fork of .gitmodules, I create a commit on top. If I want my fork of the link object, I create a link object, plus tree object, plus commit object on top of that. But the commit still rebases fine. On malleability, have you looked at [5/7], where I create edit-link (dead code; half done)? The buffer looks just like a .gitmodules buffer. Fundamentally, what is the difference between this and a blob? git-core can parse it into structured data that it can slurp easily. I don't want full float or nothing. I want in-betweens too, and refs are great. -- 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