All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ramsay Jones <ramsay@ramsayjones.plus.com>
To: Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: phillip.wood@dunelm.org.uk,
	"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org, "Slavica Đukić" <slawica92@hotmail.com>,
	"Denton Liu" <liu.denton@gmail.com>
Subject: Re: [PATCH 2/2] add -i: default to the built-in implementation
Date: Thu, 2 Dec 2021 17:43:39 +0000	[thread overview]
Message-ID: <713b6ced-cbdf-9d5d-a722-30e525a3f931@ramsayjones.plus.com> (raw)
In-Reply-To: <xmqq5ys7vt8t.fsf@gitster.g>



On 02/12/2021 16:58, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
>>>> +	if (use_builtin_add_i < 0 &&
>>>> +	    git_config_get_bool("add.interactive.usebuiltin",
>>>> +				&use_builtin_add_i))
>>>> +		use_builtin_add_i = 1;
>>>>   -	if (use_builtin_add_i == 1) {
>>>> +	if (use_builtin_add_i != 0) {
>>>
>>> This could be simplified to "if (use_builtin_add_i)" but don't re-roll just
>>> for that
>>
>> I was actually considering this, given that Git's coding practice suggests
>> precisely the form you suggested.
>>
>> However, in this instance I found that form misleading: it would read to
>> me as if `use_builtin_add_i` was a Boolean. But it is a tristate, it can
>> also be `-1` ("undecided"). And I wanted to express "if this is not set to
>> `false` specifically", therefore I ended up with my proposal.
> 
> I do not think that line of logic is sensible.  The variable starts
> its life as a tristate (i.e. not just bool but can be unknown), and
> the four new lines above the conditional the patch adds is exactly
> about getting rid of the unknown-ness and turning it into a known
> boolean.  After that happens, the variable can safely be used as a
> boolean.  In fact, I view the four lines before it is exactly to
> allow us to do so.
> 
> Writing "if not zero" implies that the variable can have a non-zero
> value that is still "unknown" at this point in the code that has to
> be defaulted to "true", which would mean that the "if unset, read
> the config, and if that fails, default to true" logic above is not
> doing its job.  That is a false impression that misleads readers of
> the code.
> 
> So, I would say this conditional just should treat the variable as a
> simple boolean.
> 

Just an FYI - I had t3701-add-interactive.sh show:

  # 2 known breakage(s) vanished; please update test(s)

on Linux tonight (tests #45 and #47).

I assumed, with little (well, any) thought, that these vanishing
breakages are due to this 'js/use-builtin-add-i' branch.

Just ignore me (and apologies in advance), if this is not the case! ;-)

ATB,
Ramsay Jones



  reply	other threads:[~2021-12-02 17:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-30 14:14 [PATCH 0/2] Use the built-in implementation of the interactive add command by default Johannes Schindelin via GitGitGadget
2021-11-30 14:14 ` [PATCH 1/2] t2016: require the PERL prereq only when necessary Johannes Schindelin via GitGitGadget
2021-12-01 22:25   ` Junio C Hamano
2021-12-02 14:57     ` Johannes Schindelin
2021-11-30 14:14 ` [PATCH 2/2] add -i: default to the built-in implementation Johannes Schindelin via GitGitGadget
2021-12-01 11:20   ` Phillip Wood
2021-12-02 15:01     ` Johannes Schindelin
2021-12-02 16:58       ` Junio C Hamano
2021-12-02 17:43         ` Ramsay Jones [this message]
2021-12-10 22:59         ` Johannes Schindelin
2021-12-01 13:37   ` Ævar Arnfjörð Bjarmason
2021-12-01 22:41     ` Junio C Hamano
2021-12-01 22:34   ` Junio C Hamano
2021-12-02 17:30     ` Johannes Schindelin
2021-12-09  4:12   ` [PATCH] fixup! " Junio C Hamano
2021-12-10 22:55     ` Johannes Schindelin
2021-11-30 20:56 ` [PATCH 0/2] Use the built-in implementation of the interactive add command by default Jeff King
2021-11-30 21:15 ` Junio C Hamano
2021-12-01 13:43 ` Ævar Arnfjörð Bjarmason
2021-12-01 21:24 ` Carlo Arenas
2021-12-02 17:33   ` Johannes Schindelin
2021-12-03 13:58 ` Philippe Blain
2021-12-06 15:59   ` Johannes Schindelin

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=713b6ced-cbdf-9d5d-a722-30e525a3f931@ramsayjones.plus.com \
    --to=ramsay@ramsayjones.plus.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=liu.denton@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=slawica92@hotmail.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.