Re: [PATCH 1/6] builtin/submodule: allow cloning with different ref storage format
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 8, 2024, 16:08 UTC
- Message-ID
- <xmqqsevfj8v2.fsf@gitster.g>
- In-Reply-To
- <ZrRtB46vu9rC000y@tanuki>
Patrick Steinhardt <ps@pks.im> writes:
Show 18 quoted lines
>> 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.