Glen Choo <chooglen@xxxxxxxxxx> 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.
> ----- >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 {
> /*
