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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Patrick Steinhardt <ps@xxxxxx> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux