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

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

Duy Nguyen <pclouds@gmail.com> writes:

> Somewhat related to the topic. Why can't .gitattributes be used for
> storing what's currently in .gitmodules?

You _could_ use gitattributes to encode, but it goes against what a
gitattributes file does or is for.  It is a mechanism to associate
groups of paths (that may not even exist) to a set of attributes.
You could list a single pattern that happens to match a single path
and at the implementation level you may be able to make it work, but
at the design/philosophical level, it is wrong.

We need info on each submodule and we need to key it with the name
of the submodule, not with its path.  At any given time, a single
submodule lives at (at most) one path, so you could still use path
as a key in the .gitattributes, but when you need to move the
submodule path, you would need to update the entry for the submodule
in .gitattributes file by finding a pattern that match the old path
and making it a pattern that match the new path.

We have a much more suitable file format that we use to associate
various values to keys: the config format.  Also having a file that
is only about submodules and nothing else means we could write a
content-aware smart ll-merge driver that can take advantage of the
knowledge that it is written in the config format and it talks about
submodules.

The answer to "why can't" question is "no".  No, there is no reason
why you can't use it. We don't do it, because it just does not make
sense.