Re: [PATCH] commit: configure submodules
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 24, 2012, 05:57 UTC
- Message-ID
- <7vmx0g0xpm.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <505F5151.2080208@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
Show 7 quoted lines
>> 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?