git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
	Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
	Git List <git@vger.kernel.org>,
	Derrick Stolee <derrickstolee@github.com>,
	Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH] for-each-repo: do nothing on empty config
Date: Wed, 06 Jan 2021 00:05:22 -0800	[thread overview]
Message-ID: <xmqqa6tmtrr1.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: db7bf751-7541-59b9-a3a0-ec07e28eb9de@gmail.com

Derrick Stolee <stolee@gmail.com> writes:

>> Probably not worth a re-roll, but the above has higher cognitive load than:
>> 
>>     if (!value)
>>         return 0;
>>
>> which indicates clearly that the command succeeded, whereas `return
>> result` makes the reader scan all the code above the conditional to
>> figure out what values `result` could possibly hold.
>
> True. Looking at this again, it might be better to just update the
> loop to be
>
> 	for (i = 0; values && i < values->nr; i++) {
>
> which would run the loop zero times when there are zero results.

It is misleading, though.  It forces readers to first assume that
the loop body may update "values" from non-NULL to NULL in some
condition and hunt for such a code in vain.

If some clean-up starts to become needed after the loop, the "if the
value array is empty, immediately return 0" may have to be rewritten
to "if empty, jump to the clean-up part after the loop", but until
then, what Eric gave us would be the easiest to read, I would think.

> To me, "nonexistent" or "does not exist" doesn't adequately describe
> this (hypothetical) situation.
>
> Perhaps "fail-subcommand" might be better?

I wonder if "false" or "exit 1" would fit the bill.  In any case, a
comment may help, perhaps?

	test_expect_success 'do nothing and succeed on empty/missing config' '
		# if this runs even once, "false" ensures a failure
		git for-each-repo --config=bogus.config -- false
	'

  parent reply	other threads:[~2021-01-06  8:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-05 14:42 [PATCH] for-each-repo: do nothing on empty config Derrick Stolee via GitGitGadget
2021-01-05 17:55 ` Eric Sunshine
2021-01-06  2:20   ` Derrick Stolee
2021-01-06  4:20     ` Eric Sunshine
2021-01-06 11:54       ` Derrick Stolee
2021-01-06 18:18         ` Eric Sunshine
2021-01-06 20:50       ` Junio C Hamano
2021-01-07  4:29         ` Eric Sunshine
2021-01-06  8:05     ` Junio C Hamano [this message]
2021-01-06 11:41       ` Derrick Stolee
2021-01-06 20:41         ` Junio C Hamano
2021-01-06 21:40           ` Junio C Hamano
2021-01-07  2:00             ` Derrick Stolee
2021-01-06 19:19 ` [PATCH v2] " Derrick Stolee via GitGitGadget
2021-01-08  2:30   ` [PATCH v3] " Derrick Stolee via GitGitGadget

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=xmqqa6tmtrr1.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=derrickstolee@github.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=stolee@gmail.com \
    --cc=sunshine@sunshineco.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).