From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 24 Sep 2012 05:57:41 GMT
Subject: Re: [PATCH] commit: configure submodules
Message-ID: <7vmx0g0xpm.fsf@alter.siamese.dyndns.org>
In-Reply-To: <505F5151.2080208@web.de>

Jens Lehmann <Jens.Lehmann@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?