Re: [PATCH v5 00/10] fetch --recurse-submodules: fetch unpopulated submodules
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 16, 2022, 23:08 UTC
- Message-ID
- <xmqqa6dpjy1g.fsf@gitster.g>
- In-Reply-To
- <kl6l7d8tle24.fsf@chooglen-macbookpro.roam.corp.google.com>
Glen Choo <chooglen@google.com> writes:
> Perhaps squashing in a NEEDSWORK comment into [PATCH v5 09/10] will > suffice? I can also resend this series if preferred.
It should work. Let me try it in the last integration cycle of today.
Show 28 quoted lines
> ----- >8 --------- >8 --------- >8 --------- >8 --------- >8 ----
>
> diff --git a/submodule.c b/submodule.c
> index 6e6b2d04e4..93c78a4dc3 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -795,6 +795,21 @@ static const char *default_name_or_path(const char *path_or_name)
> * superproject commit that points to the submodule, but this is
> * arbitrary - we can choose any (super_oid, path) that matches the
> * submodule's name.
> + *
> + * NEEDSWORK: Storing an arbitrary commit is undesirable because we can't
> + * guarantee that we're reading the commit that the user would expect. A better
> + * scheme would be to just fetch a submodule by its name. This requires two
> + * steps:
> + * - Create a function that behaves like repo_submodule_init(), but accepts a
> + * submodule name instead of treeish_name and path. This should be easy
> + * because repo_submodule_init() internally uses the submodule's name.
> + *
> + * - Replace most instances of 'struct submodule' (which is the .gitmodules
> + * config) with just the submodule name. This is OK because we expect
> + * submodule settings to be stored in .git/config (via "git submodule init"),
> + * not .gitmodules. This also lets us delete get_non_gitmodules_submodule(),
> + * which constructs a bogus 'struct submodule' for the sake of giving a
> + * placeholder name to a gitlink.
> */
> struct changed_submodule_data {
> /*