All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Taylor Blau <me@ttaylorr.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Han Jiang <jhcarl0814@gmail.com>,
	Derrick Stolee <stolee@gmail.com>
Subject: Re: [PATCH] config.c: avoid segfault with --fixed-value and valueless config
Date: Tue, 6 Aug 2024 08:17:29 +0200	[thread overview]
Message-ID: <ZrG_-Rgi85bswmId@tanuki> (raw)
In-Reply-To: <ZrEsIhWTgkdNn3I/@nand.local>

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

On Mon, Aug 05, 2024 at 03:46:42PM -0400, Taylor Blau wrote:
> On Mon, Aug 05, 2024 at 08:45:32AM -0700, Junio C Hamano wrote:
> > Patrick Steinhardt <ps@pks.im> writes:
> >
> > > Edge cases like this really make me wonder what the benefit of implicit
> > > bools is in our config files.
> > >
> > > So... why do we have them in the first place? Is there even a single
> > > good reason?
> >
> > There isn't any good reason to introduce such a syntax if we were
> > desigining the configuration file format from scratch.  It was added
> > because originally Linus thought it was a cute syntax, and these
> > days a lot lot more importantly, it is kept working because you will
> > break a lot of existing configuration files that were hand tweaked
> > if you remove the support suddenly.
> 
> I agree. It's perhaps interesting to think about in the context of the
> discussion in [1], but I think also worth having some perspective above.
> 
> Sure, this configuration syntax would not be invented anew today, but I
> also don't think it's worth breaking existing configurations, even in a
> hypothetical "Git 3.0" release.
> 
> In some sense I am sympathetic to Patrick's argument, but I also think
> that having a bug in a relatively niche feature like --fixed-value that
> wasn't noticed for almost four years over 17 [2] releases isn't itself a
> strong argument for removing the feature.

I was really just wondering whether there is actually a good reason to
have it that I couldn't think of. I certainly think that this feature
shouldn't exist, but also agree that removing it now would create more
hassle than benefit.

Thanks for the context!

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2024-08-06  6:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-01 17:06 [PATCH] config.c: avoid segfault with --fixed-value and valueless config Taylor Blau
2024-08-05 12:38 ` Patrick Steinhardt
2024-08-05 15:45   ` Junio C Hamano
2024-08-05 19:46     ` Taylor Blau
2024-08-06  6:17       ` Patrick Steinhardt [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=ZrG_-Rgi85bswmId@tanuki \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jhcarl0814@gmail.com \
    --cc=me@ttaylorr.com \
    --cc=stolee@gmail.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.