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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 8, 2013, 17:12 UTC
Message-ID: <7vy5ctx7xj.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7v61zx13nv.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 18 quoted lines

> Jonathan Nieder <jrnieder@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).