From: Jon Seymour <jon.seymour@gmail.com>
Date: Wed, 18 Aug 2010 23:02:32 GMT
Subject: Re: RFD: should git rev-parse exit with non-zero status if ref@{n} is not valid?
Message-ID: <AANLkTi=m7+h0nVg+EAmiir-rnrjoBwbpLtztcNNBVxiz@mail.gmail.com>
In-Reply-To: <7vsk2b8x2t.fsf@alter.siamese.dyndns.org>

Thanks for that. Not quite sure why yet, but the error message is
duplicated. I wonder also if the free() call at the end of the
function needs to be duplicated before the early return?

Anyway, I am happy to look at this. Would you prefer this to be
delivered as a separate patch or can I re-roll it at the base of
detached-stash? (I realise I have to re-roll v5 anyway, because some
of the later tests don't quite reflect the intent (e.g. ! git stash
stash@{0} should be ! git stash drop stash@{0}).

jon.

On Thu, Aug 19, 2010 at 6:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> I understand why ref@{time-spec} might behave this way, but I reckon
>> that if you ask for ref@{n} for n > N-1, where N is the length of the
>> reflog, then you should either get empty output and a non-zero status
>> (preferred) or a ref@{N-1} on the output with a status code of zero
>> and a warning message (less optimal, IMHO).
>
> Yeah, the behaviour of ref@{...} syntax parser is way suboptimal:
>
>    $ git rev-parse --verify jch@{99999}; echo $?
>    warning: Log for 'jch' only has 1368 entries.
>    cfb88e9a8d4926b0011ae2dd67e1f57a98f4b768
>    0
>
> It even knows that it is running off the cut-off point; it should just
> cause the caller to notice that fact.  I don't think changing it to error
> out should cause any harm to existing callers.
>
> It may just be the matter of doing something like this (totally
> untested)...
>
>  sha1_name.c |   12 +++++-------
>  1 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/sha1_name.c b/sha1_name.c
> index 4af94fa..c1e51c9 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -342,7 +342,7 @@ static int get_sha1_1(const char *name, int len, unsigned char *sha1);
>
>  static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
>  {
> -       static const char *warning = "warning: refname '%.*s' is ambiguous.\n";
> +       static const char *warn_msg = "warning: refname '%.*s' is ambiguous.\n";
>        char *real_ref = NULL;
>        int refs_found = 0;
>        int at, reflog_len;
> @@ -390,7 +390,7 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
>                return -1;
>
>        if (warn_ambiguous_refs && refs_found > 1)
> -               fprintf(stderr, warning, len, str);
> +               fprintf(stderr, warn_msg, len, str);
>
>        if (reflog_len) {
>                int nth, i;
> @@ -426,14 +426,12 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
>                if (read_ref_at(real_ref, at_time, nth, sha1, NULL,
>                                &co_time, &co_tz, &co_cnt)) {
>                        if (at_time)
> -                               fprintf(stderr,
> -                                       "warning: Log for '%.*s' only goes "
> +                               warning("Log for '%.*s' only goes "
>                                        "back to %s.\n", len, str,
>                                        show_date(co_time, co_tz, DATE_RFC2822));
>                        else
> -                               fprintf(stderr,
> -                                       "warning: Log for '%.*s' only has "
> -                                       "%d entries.\n", len, str, co_cnt);
> +                               return error("Log for '%.*s' only has "
> +                                            "%d entries.\n", len, str, co_cnt);
>                }
>        }
>
>