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: Wed, 27 Sep 2023 12:56:39 -0700 [thread overview]
Message-ID: <xmqqwmwbl79k.fsf@gitster.g> (raw)
In-Reply-To: <87r0mjn4ly.fsf@gmail.froward.int.ebiederm.org> (Eric W. Biederman's message of "Wed, 27 Sep 2023 08:11:05 -0500")
"Eric W. Biederman" <ebiederm@gmail.com> writes:
> For me the fundamental question is if we allow multiples compatibility
> hashes or historical hashes how do we specify them? Have the option
> appear more than once? A comma separated list?
As you found out, we tend to use both, but the former does look more
natural to me.
The "usual" pros and cons [*] involve how easy it is to override the
settings given by more general low-priority configuration files with
more specific high-priority configuration files, and does not apply
to the extensions.* stuff that are by definition repository
specific.
[Footnote]
As I said, this does not apply to the topic of this discussion, but
just for completeness:
* comma separated list allows overriding everything that was said
earlier wholesale; there is no ambiguity, which is a plus, but
there is no incremental updates, which may be a minus when
flexibility is desired.
* multi-valued configuration variable allows incremental additions,
but ad-hoc syntax needs to be invented if incremental
subtractions or clearing the slate to start from scratch is
needed.
prev parent reply other threads:[~2023-09-27 19:57 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
2023-09-27 13:11 ` Eric W. Biederman
2023-09-27 19:56 ` Junio C Hamano [this message]
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=xmqqwmwbl79k.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 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.