All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/2] sha1_name: don't trigger detailed diagnosis for file arguments
Date: Mon, 18 Jun 2012 19:56:56 +0200	[thread overview]
Message-ID: <vpqipeopkpj.fsf@bauges.imag.fr> (raw)
In-Reply-To: <7v62ao4ihf.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Mon, 18 Jun 2012 10:50:36 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> My version reads as
>>
>>   try something;
>>   if (it failed && I'm only here to report an error)
>>           report_error();
>>
>> which I find easier to understand.
>
> I agree that _this_ part is easy to understand when written that
> way.  But then shouldn't there be a blanket "The caller is here only
> to report an error, but all the previous code didn't find any error,
> so there is something wrong" check much later in the code before it
> returns a success?  Or am I being too paranoid?

Currently, there's no problem if get_sha1_with_context_1 returns without
dying, because the caller does:

	if (!(arg[0] == ':' && !isalnum(arg[1])))
		/* try a detailed diagnostic ... */
		get_sha1_with_mode_1(arg, sha1, &mode, 1, prefix);

	/* ... or fall back the most general message. */
	die("ambiguous argument '%s': unknown revision or path not in the working tree.\n"
	    "Use '--' to separate paths from revisions", arg);

If we failed to give a nice diagnosis, we give the generic error
message.

We could add this check within get_sha1_with_context_1 to simplify the
task of the caller, but that would require adding it before each
"return" statement, which I think is overkill.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

  reply	other threads:[~2012-06-18 17:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-15  4:03 "Detailed diagnosis" perhaps broken Junio C Hamano
2012-06-17 18:34 ` Matthieu Moy
2012-06-17 18:39   ` [PATCH 1/2] sha1_name: don't trigger detailed diagnosis for file arguments Matthieu Moy
2012-06-17 18:39     ` [PATCH 2/2 RFC] verify_filename: ask the caller to chose the kind of diagnosis Matthieu Moy
2012-06-17 20:22       ` Junio C Hamano
2012-06-18  6:42         ` Matthieu Moy
2012-06-18 16:27           ` Junio C Hamano
2012-06-18 18:18             ` [PATCH 1/2 v2] sha1_name: don't trigger detailed diagnosis for file arguments Matthieu Moy
2012-06-18 18:18               ` [PATCH 2/2 v2] verify_filename: ask the caller to chose the kind of diagnosis Matthieu Moy
2012-06-18 22:25                 ` Junio C Hamano
2012-06-19 11:17                   ` Matthieu Moy
2012-06-18 17:23     ` [PATCH 1/2] sha1_name: don't trigger detailed diagnosis for file arguments Junio C Hamano
2012-06-18 17:42       ` Matthieu Moy
2012-06-18 17:50         ` Junio C Hamano
2012-06-18 17:56           ` Matthieu Moy [this message]
2012-06-18 18:01             ` Junio C Hamano

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=vpqipeopkpj.fsf@bauges.imag.fr \
    --to=matthieu.moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.