From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Steffen Prohaska <prohaska@zib.de>,
git@vger.kernel.org, pclouds@gmail.com, john@keeping.me.uk,
schacon@gmail.com
Subject: Re: [PATCH v6 2/6] Add git_env_ulong() to parse environment variable
Date: Wed, 27 Aug 2014 00:46:21 -0400 [thread overview]
Message-ID: <20140827044621.GA32141@peff.net> (raw)
In-Reply-To: <xmqq38cihq7w.fsf@gitster.dls.corp.google.com>
On Tue, Aug 26, 2014 at 02:54:11PM -0700, Junio C Hamano wrote:
> A worse position is to have git_env_bool() that says "empty is
> false" and add a new git_env_ulong() that says "empty is unset".
>
> We should pick one or the other and use it for both.
Yeah, I agree they should probably behave the same.
> > The middle ground would be to die(). That does not seem super-friendly, but
> > then we would also die with GIT_SMART_HTTP=foobar, so perhaps it is not
> > unreasonable to just consider it a syntax error.
>
> Hmm, I am not sure if dying is better. Unless we decide to make
> empty string no longer false everywhere and warn now and then later
> die as part of a 3.0 transition plan or something, that is.
I think it is better in the sense that while it may be unexpected, it
does not unexpectedly do something that the user cannot easily undo.
I really do not think this topic is worth the effort of a long-term
deprecation scheme (which I agree _is_ required for a change to the
config behavior). Let's just leave it as-is. We've seen zero real-world
complaints, only my own surprise after reading the code (and Steffen's
patch should be tweaked to match).
-Peff
next prev parent reply other threads:[~2014-08-27 4:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 15:23 [PATCH v6 0/6] Stream fd to clean filter; GIT_MMAP_LIMIT, GIT_ALLOC_LIMIT with git_env_ulong() Steffen Prohaska
2014-08-26 15:23 ` [PATCH v6 1/6] convert: drop arguments other than 'path' from would_convert_to_git() Steffen Prohaska
2014-08-26 15:23 ` [PATCH v6 2/6] Add git_env_ulong() to parse environment variable Steffen Prohaska
2014-08-26 18:21 ` Jeff King
2014-08-26 20:20 ` Junio C Hamano
2014-08-26 20:31 ` Jeff King
2014-08-26 21:54 ` Junio C Hamano
2014-08-27 4:46 ` Jeff King [this message]
2014-08-27 14:47 ` Junio C Hamano
2014-08-28 15:21 ` Steffen Prohaska
2014-08-28 17:13 ` Junio C Hamano
2014-08-26 15:23 ` [PATCH v6 3/6] Change GIT_ALLOC_LIMIT check to use git_env_ulong() Steffen Prohaska
2014-08-26 15:23 ` [PATCH v6 4/6] Introduce GIT_MMAP_LIMIT to allow testing expected mmap size Steffen Prohaska
2014-08-26 15:23 ` [PATCH v6 5/6] Change copy_fd() to not close input fd Steffen Prohaska
2014-08-26 17:10 ` Junio C Hamano
2014-08-26 18:29 ` Jeff King
2014-08-28 15:37 ` Steffen Prohaska
2014-08-28 17:15 ` Junio C Hamano
2014-08-26 15:23 ` [PATCH v6 6/6] convert: stream from fd to required clean filter to reduce used address space Steffen Prohaska
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=20140827044621.GA32141@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=john@keeping.me.uk \
--cc=pclouds@gmail.com \
--cc=prohaska@zib.de \
--cc=schacon@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.