From: Jay Soffian <jaysoffian@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Bill Pemberton <wfp5p@virginia.edu>,
git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH 3/6] Remove return undef from ask()
Date: Sun, 3 May 2009 22:26:25 -0400 [thread overview]
Message-ID: <76718490905031926i771b0234ua7b45d5e0d827913@mail.gmail.com> (raw)
In-Reply-To: <20090503202625.GC20468@coredump.intra.peff.net>
On Sun, May 3, 2009 at 4:26 PM, Jeff King <peff@peff.net> wrote:
> On a side note, while looking at this function, I wonder if that "return
> undef" is correct after all. We get there only if the user has failed to
> give valid input 10 times, so presumably it is a sanity check to
> prevent runaway input errors
Correct, that is why it is there.
> (and I am cc'ing Jay, who added the
> function not too long ago). Should we be respecting the default here, as
> we do when we get EOF?
The original motivation was a user who was running send-email from
cron and it was looping forever. That case is now actually handled
before the loop, and all other normal cases are handled inside the
loop.
So the only thing that can cause the loop to exit (AFAIK) is when
$valid_re is passed in and the user provides invalid input 10x.
> Although I tend to think if the user is
> repeatedly giving us bogus input that we should not just proceed, but
> should probably die. Because otherwise we are guessing at what they
> might have wanted.
Well, it returns undef, at which point it's up to the caller to figure
out what to do. You'll notice the one caller which passes in $valid_re
dies:
die "Send this email reply required" unless defined $_;
Letting the caller decide what to do provides more flexibility.
j.
next prev parent reply other threads:[~2009-05-04 2:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-29 13:12 [PATCH 0/6] cleanups for git-send-email Bill Pemberton
2009-04-29 13:12 ` [PATCH 1/6] Remove return undef from validate_patch Bill Pemberton
2009-04-29 13:12 ` [PATCH 2/6] Remove function prototypes from git-send-email.perl Bill Pemberton
2009-04-29 13:12 ` [PATCH 3/6] Remove return undef from ask() Bill Pemberton
2009-04-29 13:12 ` [PATCH 4/6] Add explict return to end of subroutines Bill Pemberton
2009-04-29 13:12 ` [PATCH 5/6] Remove mix of high and low-precedence booleans Bill Pemberton
2009-04-29 13:12 ` [PATCH 6/6] Remove bareword filehandles in git-send-email.perl Bill Pemberton
2009-05-03 20:58 ` Jeff King
2009-05-03 21:34 ` Francis Galiegue
2009-05-04 6:12 ` H.Merijn Brand
2009-05-04 6:53 ` Francis Galiegue
2009-05-04 7:41 ` H.Merijn Brand
2009-04-29 16:54 ` [PATCH 5/6] Re: Remove mix of high and low-precedence booleans Nicolas Sebrecht
2009-04-29 17:00 ` Bill Pemberton
2009-05-03 20:31 ` [PATCH 4/6] Add explict return to end of subroutines Jeff King
2009-05-03 20:26 ` [PATCH 3/6] Remove return undef from ask() Jeff King
2009-05-04 2:26 ` Jay Soffian [this message]
2009-05-03 20:27 ` [PATCH 2/6] Remove function prototypes from git-send-email.perl Jeff King
2009-05-03 19:46 ` [PATCH 1/6] Remove return undef from validate_patch Jeff King
2009-04-29 19:18 ` [PATCH 0/6] cleanups for git-send-email Junio C Hamano
2009-04-29 19:48 ` Bill Pemberton
2009-04-29 20:23 ` Junio C Hamano
2009-04-29 22:27 ` [PATCH 0/6] " Nicolas Sebrecht
2009-04-30 8:11 ` Andreas Ericsson
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=76718490905031926i771b0234ua7b45d5e0d827913@mail.gmail.com \
--to=jaysoffian@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=wfp5p@virginia.edu \
/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).