Re: [RFC/PATCH 0/7] Rework git core for native submodules

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