Re: [PATCH v5 00/10] fetch --recurse-submodules: fetch unpopulated submodules

From: Glen Choo <chooglen@google.com>
Date: Mar 8, 2022, 18:24 UTC
Message-ID: <kl6lh7885mm3.fsf@chooglen-macbookpro.roam.corp.google.com>
In-Reply-To: <xmqqr17dp8s9.fsf@gitster.g>

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

Show 13 quoted lines

> Glen Choo <chooglen@google.com> 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.