Junio C Hamano <gits...@pobox.com> writes:
> Jonathan Nieder <jrnie...@gmail.com> writes:
>
> [snipped everything I agree with...]
>
>> On the other hand, the single .gitmodules file will be a pain to merge
>> if multiple branches modify it. So I do look forward to a merge
>> strategy that deals more intelligently with its content, and wouldn't
>> have minded a design that split this information into multiple files
>> if we were starting over.
>
> I find it a sensible suggestion to have a content-aware merge
> driver. Such a custom merge driver to help merging a structured
> datafile in the config format will have other uses when we need to
> do more than the current system (outside submodules there will be
> other things "frotz" that need "information about frotz" in the
> future, and a .gitfrotz file would be one possible way to do so).
>
> I do not think it needs to be split per-submodule.
Another thing to think about is what to do when/if we want to
express "this is the default that applies to all submodules". For
example, a superproject that binds multiple submodules may want to
say "When on this branch, make all submodules also on 'next'".
With a unified single place that holds information about all
submodules, it is trivial to add a "default" section, perhaps like
this:
[default]
branch = next
[submodule "framework"]
url = ...
path = framework
[submodule "common"]
url = ...
path = common
branch = master ;# regardless of other modules...
on top of the "submodule.<name>.branch" mechanism for floating
checkout (the "default" is of course not limited to "branch" but
applies in general).
It is not obvious where such a "default" piece should go once you
start splitting these into per-submodule files, be it a separate but
still in-tree file that is different from the submodule it desribes,
or a blob-like object that sits at the path for the submodule in the
tree and in the index as Ram wants to do (as I kept saying, the
storage mechanism is not fundamental).
This is similar to why .gitattributes is easy to work with, I think.
You can describe the information about paths in that file (which
lives at a place different from the paths that are described), and
you can have a catch-all rule in it.
This is a tangent, but you could build a system that attaches
attributes to individual paths and hide the attributes from the
working tree filesystem (think: svn:blah) and have a set of special
commands (think: svn propset, proplist, etc.) to work with them, and
that is an equally valid way to implement attributes (it does not
make .gitattributes less valid way to do so, though).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
