Junio C Hamano <gitster@xxxxxxxxx> writes: > Jens Lehmann <Jens.Lehmann@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html