Re: [PATCH] commit: configure submodules

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 23.09.2012 10:37, schrieb Junio C Hamano:
> I see Jens added with 302ad7a (Submodules: Use "ignore" settings
> from .gitmodules too for diff and status, 2010-08-06) the call to
> gitmodules_config() to "git status" and "git diff" family, but I
> suspect that was a huge mistake.  Once a submodule is initialized
> with "submodule init", the default set of configuration should be
> copied to the user's $GIT_DIR/config and subsequent run-time
> invocation should read $GIT_DIR/config and $GIT_DIR/config alone, to
> honor user's customization.

Not honoring the user's customization would be a big mistake, but
this is not what happens here. A setting in $GIT_DIR/config always
overrides the one in .gitmodules (that's why gitmodules_config() is
called before git_config()).

> Instead, I think git_commit_config() and git_status_config() should
> call submodule_config() function to read submodule.$name.ignore not
> from .gitmodules file but from $GIT_DIR/config.
> 
> Jens, what do you think?  I see no reason for anybody other than
> "submodule init" to call gitmodules_config() that reads from the
> in-tree .gitmodules file.

I think the copying on init is not what we should do here because
it sets the user's customization to what ever happened to be in
.gitmodules at the time he initialized the submodule. Later changes
from upstream to such a setting would not be honored unless the
user copies that new setting herself (which I think is The Right
Thing for the URL, but not for the other work tree related settings
like 'ignore').

Imagine you have a submodule containing a huge media file which is
set to be ignored for performance reasons. When upstream later
decides it should rather use .gitattributes to just disable diffing
that file and removes the submodule ignore so the users see changes
to other files of the submodule again, that will just work the way
it is done now, but won't when we copy that setting on init.

So it is either "honor upstream unless the user decides otherwise"
or "take what upstream configured at init time as the users choice
(until he actively changes it)". And I think the former is more
flexible as it allows upstream to change settings without user
intervention, which is why I did it that way.

And as I understand that .gitattributes follow the same principle:
Unless the user configured something different in his
$GIT_DIR/info/attributes file, git will use the settings from the
.gitattributes file of the currently checked out commit.

So I think Orgad's change is sane and should go in.