Re: [PATCH] config.c: avoid segfault with --fixed-value and valueless config

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxx> 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: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux