From: Junio C Hamano <gitster@pobox.com>
To: "Eric W. Biederman" <ebiederm@gmail.com>
Cc: <git@vger.kernel.org>, "brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH] setup: Only allow extenions.objectFormat to be specified once
Date: Tue, 26 Sep 2023 14:37:36 -0700 [thread overview]
Message-ID: <xmqqr0mkmx9b.fsf@gitster.g> (raw)
In-Reply-To: <87h6ngapqb.fsf@gmail.froward.int.ebiederm.org> (Eric W. Biederman's message of "Tue, 26 Sep 2023 11:01:00 -0500")
"Eric W. Biederman" <ebiederm@gmail.com> writes:
> Today there is no sanity checking of what happens when
> extensions.objectFormat is specified multiple times. Catch confused git
> configurations by only allowing this option to be specified once.
Hmph. I am not sure if this is worth doing, and especially only for
"objectformat". Do we intend to apply different rules other than
"you can give it only once" to other extensions, and if so where
will these rules be catalogued? I do not see particular harm to let
them follow the usual "last one wins".
If the patch were about trying to make sure that extensions, which
are inherentaly per-repository, appear only in $GIT_DIR/config and
complain if the code gets confused and tried to read them from the
system or global configuration files, I would understand, and
strongly support such an effort, ithough.
The real sanity we want to enforce is that what is reported by
running "git config extensions.objectformat" must match the object
format that is used in refs and object database. Manually futzing
the configuration file and adding an entry with a contradictory
value certainly is one way to break that sanity, and this patch may
catch such a breakage, but once we start worrying about manually
futzing the configuration file, the check added here would easily
miss if the futzing is done by replacing instead of adding, so I am
not sure if this extra code is worth its bits.
But perhaps I am missing something and not seeing why it is worth
insisting on "last one is the first one" for this particular one.
Thanks.
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
> setup.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/setup.c b/setup.c
> index 18927a847b86..ef9f79b8885e 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -580,6 +580,7 @@ static enum extension_result handle_extension(const char *var,
> if (!strcmp(ext, "noop-v1")) {
> return EXTENSION_OK;
> } else if (!strcmp(ext, "objectformat")) {
> + struct string_list_item *item;
> int format;
>
> if (!value)
> @@ -588,6 +589,13 @@ static enum extension_result handle_extension(const char *var,
> if (format == GIT_HASH_UNKNOWN)
> return error(_("invalid value for '%s': '%s'"),
> "extensions.objectformat", value);
> + /* Only support objectFormat being specified once. */
> + for_each_string_list_item(item, &data->v1_only_extensions) {
> + if (!strcmp(item->string, "objectformat"))
> + return error(_("'%s' already specified as '%s'"),
> + "extensions.objectformat",
> + hash_algos[data->hash_algo].name);
> + }
> data->hash_algo = format;
> return EXTENSION_OK;
> }
next prev parent reply other threads:[~2023-09-27 2:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 16:01 [PATCH] setup: Only allow extenions.objectFormat to be specified once Eric W. Biederman
2023-09-26 21:37 ` Junio C Hamano [this message]
2023-09-27 13:11 ` Eric W. Biederman
2023-09-27 19:56 ` 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=xmqqr0mkmx9b.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ebiederm@gmail.com \
--cc=git@vger.kernel.org \
--cc=sandals@crustytoothpaste.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).