Junio C Hamano <gitster@xxxxxxxxx> writes: > Glen Choo <chooglen@xxxxxxxxxx> writes: > >> It's true that we don't need <.super_oid, .path> in order to init the >> subrepo, but it turns out that recursive fetch reads some >> configuration values from .gitmodules (via submodule_from_path()), so >> we still need to store super_oid in order to read the correct >> .gitmodules file. > > OK, but then do we know which .gitmodules file is the "correct" one, > when there are more than one .super_oid? Or do we assume that > .gitmodules does not change in the range of superproject commits we > have fetched before deciding what commits need to be fetched in the > submodules? This uses a "first one wins approach", which obviously doesn't have correctness guarantees. But in practice, I don't think this is likely to cause problems: - As far as I can tell, the only value we read from .gitmodules is 'submodule.<name>.fetchRecurseSubmodules', and this value gets overridden by two other values: the CLI option, and the config variable with the same name in .git/config. During "git submodule init", we copy the config values from .gitmodules to .git/config. Since we can only fetch init-ed submodules anyway, it's quite unlikely that we will ever actually make use of the .gitmodules config. - Even if we do use the .gitmodules config values, it's unlikely that the values in .gitmodules will change often, so it _probably_ won't matter which one we choose. - This only matters when the submodule is not in the index. If the submodule _is_ in the index, we read .gitmodules from the filesystem i.e. these patches shouldn't change the behavior for submodules in the index.
