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

[Junio C Hamano <gitster@pobox.com>]

Jens Lehmann <Jens.Lehmann@web.de> writes:

> While starting to grok submodules I was wondering myself if the data
> stored in .gitmodules would better be stored in an extended gitlink
> object, but I learned soon that the scope of the data that has to be
> stored there was not clear at that time (and still isn't). So I'm
> not opposed per se to adding a special object containing all that
> information, but I strongly believe we are not even close to
> considering such a step (and won't be for quite some time and maybe
> never will).

I actually think the storage is more or less an orthogonal issue.

The format must be defined to be extensible (nobody is perfect and
if you wait for an exhaustive list of attributes that cover all use
cases including the ones that haven't even been invented yet, you
will get nowhere), and designed carefully to reduce the chance of
allowing the extended/optional bit to express the same thing in two
different ways to make sure the object name will not become
unnecessarily unstable, but you can start small, keep adding
optional fields, and be prepared to design an upgrade path when you
need to add new mandatory fields---that cannot be helped whether you
record the information about submodules in .gitmodules or a new
blob-ish object at the location where the submodule tree should
reside in the index and the tree.

However, the current .gitmodules design, even though it originally
was invented as a way to carry information other than what a single
commit object name from an otherwise unrelated project can express
without having to change anything in-core, has a few practical
merits.  The information _about_ submodules is stored separately
(i.e. in the .gitmodules file) from submodules themselves, and it
may be a good thing.

When you are changing information _about_ submodules (e.g. you may
be updating the recommended URL to fetch it from), you can use the
usual tools like "git diff" to see how it changed, just like changes
to any other file.  If the information _about_ a submodule A is
stored at path A, and at the same time you have a working tree that
corresponds to the root of the submodule A at that path, it gets
unclear what "git diff A" should report.  Should it report the
change in the submodule itself, or should it report the change in
the information _about_ the submodule?  By separating these two
concepts to two different places, .gitmodules design solves the
issue nicely.