Re: [PATCH] commit: configure submodules

From: Jens Lehmann <jens.lehmann@web.de>
Date: Sep 23, 2012, 18:13 UTC
Message-ID: <505F5151.2080208@web.de>
In-Reply-To: <7vr4pt16ep.fsf@alter.siamese.dyndns.org>

Am 23.09.2012 10:37, schrieb Junio C Hamano:

Show 8 quoted lines

> 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()).

Show 7 quoted lines

> 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.