On August 8, 2024 6:08:01 PM GMT+02:00, Junio C Hamano <gitster@xxxxxxxxx> wrote: >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. The documentation already points this out, as we explicitly say that it only has an impact on newly cloned submodules: > If `--ref-format <format>` is specified, the ref storage format of newly cloned submodules will be set accordingly. I'm happy to make this more explicit though, in case you don't think this is sufficient. Patrick
