From: Junio C Hamano <gitster@pobox.com>
To: Jon Seymour <jon.seymour@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/4] rev-parse: suppress duplicate log limit exceeded message.
Date: Mon, 23 Aug 2010 09:33:57 -0700 [thread overview]
Message-ID: <7vr5hp1e6i.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: AANLkTi=3=sumzcSFoCN6FUPQPzfQvfSim8KPRoXoT3tL@mail.gmail.com
Jon Seymour <jon.seymour@gmail.com> writes:
> Ideally, I think we should simply be reporting the log limit exceeded
> condition as a fatal condition on its own, and not reporting the
> ambiguous ref catch all at all in this case. We have already decided
> that the argument is a reference at this point and as such it is not
> really ambiguous, it just happens to be out of bounds.
A very good point. Would simply replacing that error-then-return-nonzero
with a die work? If so we do not even need to worry about new mechanisms
to cause different soft error conditions reported back to the caller to be
printed.
next prev parent reply other threads:[~2010-08-23 16:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-18 11:36 RFD: should git rev-parse exit with non-zero status if ref@{n} is not valid? Jon Seymour
2010-08-18 11:41 ` Jon Seymour
2010-08-18 20:50 ` Junio C Hamano
2010-08-18 23:02 ` Jon Seymour
2010-08-21 1:43 ` [PATCH 0/4] rev-parse: improve reporting of invalid log references Jon Seymour
2010-08-21 1:43 ` [PATCH 1/4] rev-parse: exit with non-zero status if ref@{n} is not valid Jon Seymour
2010-08-21 1:43 ` [PATCH 2/4] rev-parse: suppress duplicate log limit exceeded message Jon Seymour
2010-08-22 21:20 ` Junio C Hamano
2010-08-23 14:59 ` Jon Seymour
2010-08-23 16:33 ` Junio C Hamano [this message]
2010-08-23 23:11 ` [PATCH v2 0/2] rev-parse: strengthen validation of ref@{n} references Jon Seymour
2010-08-23 23:11 ` [PATCH v2 1/2] rev-parse: exit with non-zero status if ref@{n} is not valid Jon Seymour
2010-08-24 0:14 ` Jonathan Nieder
2010-08-24 4:52 ` [PATCH v3 0/3] rev-parse: strengthen validation of ref@{n} references Jon Seymour
2010-08-24 4:52 ` [PATCH v3 1/3] rev-parse: exit with non-zero status if ref@{n} is not valid Jon Seymour
2010-08-24 4:52 ` [PATCH v3 2/3] sha1_name.c: use warning in preference to fprintf(stderr Jon Seymour
2010-08-24 4:52 ` [PATCH v3 3/3] rev-parse: tests git rev-parse --verify master@{n}, for various n Jon Seymour
2010-08-23 23:11 ` [PATCH v2 2/2] " Jon Seymour
2010-08-21 1:43 ` [PATCH 3/4] rev-parse: introduce get_sha1_gently Jon Seymour
2010-08-21 1:43 ` [PATCH 4/4] rev-parse: tests that git rev-parse --verify master@{n} Jon Seymour
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=7vr5hp1e6i.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jon.seymour@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 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).