Re: [PATCH 1/6] builtin/submodule: allow cloning with different ref storage format

>Patrick Steinhardt <ps@pks.im> writes:
>
>>> Presumably, if the named submodule has already been initialized, we
>>> are not converting its ref backend with --ref-format=<format> option
>>> when "git submodule update --ref-format=<format>" is run.  Would it
>>> make sense to say it is an error to give it without "--init", I
>>> wonder.  If so, we probably would need to see if other existing
>>> options like "--filter" also need a similar sanity check, if not
>>> already done.
>>
>> Well, even when "--init" was given it is not sure whether the ref
>> storage format will actually end up being used, because that option only
>> tells us to initialize uninitialized submodules. So if the submodule was
>> initialized already, then the ref storage format won't be used.
>>
>> We probably could add such a sanity check. But as you say, other options
>> like "--filter", "--depth", "--reference" and "--recommend-shallow"
>> don't have that check, either, so it would feel a bit like opening a can
>> of worms. So personally, I'd rather defer this to another day where we
>> then implement the check for all of these options.
>
>I am perfectly fine if we stopped by clearly documenting that these
>options can be no-op when the submodule repository already exists.
>Failing the operation in the name of "sanity check" at this point,
>especially for existing options, does not sound like a sensible
>change.
>
>Thanks.