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

> Jens Lehmann <jens.lehm...@web.de> writes:
>>> 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.
> Hrm, why does the user have submodule.$name.$whatever customized
> before saying "submodule init $whategver" for that copying to be
> problematic?
>> So I think Orgad's change is sane and should go in.
> Matching what cmd_commit() does to what cmd_status() does, i.e. grab
> submodule.$name.ignore from somewhere, is not something I questioned.
> The patch is a good change to make them consistent.
> What I was wondering was if that is a consistently wrong thing to do
> to read from .gitmodules not $GIT_DIR/config.
> In any case, the log message I suggested in the review needs to be
> updated in the reroll to make it clear that this is about reading
> from .gitmodules, not "configuration".  AFAICS, gitmodule_config()
> does not even read from $GIT_DIR/config, right?

OK.  gitmodule_config() does not read $GIT_DIR/config, but
cmd_status() and cmd_commit() call git_diff_basic_config() that is
called from git_diff_ui_config() to read submodule.$name.ignore from
it.  So Orgad's patch is _only_ about submodule.$name.ignore that is
in in-tree .gitmodule; the log message shouldn't mention "config",
as setting configuration variables work for both status and commit
just fine.

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

Reply via email to