From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, "Eric Sunshine" <sunshine@sunshineco.com>,
"Jeppe Øland" <joland@gmail.com>
Subject: Re: [PATCH 1/6] builtin/submodule: allow cloning with different ref storage format
Date: Thu, 08 Aug 2024 09:08:01 -0700 [thread overview]
Message-ID: <xmqqsevfj8v2.fsf@gitster.g> (raw)
In-Reply-To: <ZrRtB46vu9rC000y@tanuki> (Patrick Steinhardt's message of "Thu, 8 Aug 2024 09:00:23 +0200")
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.
next prev parent reply other threads:[~2024-08-08 16:08 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-05 11:31 2.46 submodule breakage Jeppe Øland
2024-08-06 13:18 ` Jeppe Øland
2024-08-06 18:26 ` Eric Sunshine
2024-08-07 6:40 ` Patrick Steinhardt
2024-08-07 7:38 ` Patrick Steinhardt
2024-08-07 16:09 ` Junio C Hamano
2024-08-07 12:43 ` [PATCH 0/6] Improvements for ref storage formats with submodules Patrick Steinhardt
2024-08-07 12:43 ` [PATCH 1/6] builtin/submodule: allow cloning with different ref storage format Patrick Steinhardt
2024-08-07 14:45 ` [PATCH 0/6] Improvements for ref storage formats with submodules Jeppe Øland
2024-08-07 22:55 ` [PATCH 1/6] builtin/submodule: allow cloning with different ref storage format Junio C Hamano
2024-08-08 7:00 ` Patrick Steinhardt
2024-08-08 16:08 ` Junio C Hamano [this message]
2024-08-08 16:19 ` Patrick Steinhardt
2024-08-08 17:26 ` Junio C Hamano
2024-08-07 12:43 ` [PATCH 2/6] builtin/clone: propagate ref storage format to submodules Patrick Steinhardt
2024-08-07 23:07 ` Junio C Hamano
2024-08-07 12:43 ` [PATCH 3/6] refs: fix ref storage format for submodule ref stores Patrick Steinhardt
2024-08-07 12:44 ` [PATCH 4/6] submodule: fix leaking fetch tasks Patrick Steinhardt
2024-08-07 12:44 ` [PATCH 5/6] submodule: fix leaking seen submodule names Patrick Steinhardt
2024-08-07 12:44 ` [PATCH 6/6] object: fix leaking packfiles when closing object store Patrick Steinhardt
2024-08-07 13:18 ` [PATCH 0/6] Improvements for ref storage formats with submodules Patrick Steinhardt
2024-08-08 1:09 ` Junio C Hamano
2024-08-08 7:00 ` Patrick Steinhardt
2024-08-08 7:35 ` [PATCH v2 0/8] " Patrick Steinhardt
2024-08-08 7:35 ` [PATCH v2 1/8] git-submodule.sh: break overly long command lines Patrick Steinhardt
2024-08-08 7:35 ` [PATCH v2 2/8] builtin/submodule: allow cloning with different ref storage format Patrick Steinhardt
2024-08-08 7:35 ` [PATCH v2 3/8] builtin/clone: propagate ref storage format to submodules Patrick Steinhardt
2024-08-08 8:03 ` Kristoffer Haugsbakk
2024-08-08 13:29 ` Patrick Steinhardt
2024-08-08 7:35 ` [PATCH v2 4/8] refs: fix ref storage format for submodule ref stores Patrick Steinhardt
2024-08-08 7:35 ` [PATCH v2 5/8] builtin/submodule: allow "add" to use different ref storage format Patrick Steinhardt
2024-08-08 7:35 ` [PATCH v2 6/8] submodule: fix leaking fetch tasks Patrick Steinhardt
2024-08-08 7:35 ` [PATCH v2 7/8] submodule: fix leaking seen submodule names Patrick Steinhardt
2024-08-08 7:36 ` [PATCH v2 8/8] object: fix leaking packfiles when closing object store Patrick Steinhardt
2024-08-08 16:24 ` [PATCH v2 0/8] Improvements for ref storage formats with submodules Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqsevfj8v2.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=joland@gmail.com \
--cc=ps@pks.im \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.