David Aguilar <davvid@xxxxxxxxx> writes:
> Subject: Re: [PATCH 2/2] rev-parse: honor --quiet when asking for reflog dates that do not exist
> ...
> Make rev-parse --verify --quiet ref@{1.year.ago} when the reflog
> does not go back that far succeed silently with --quiet.
> ...
> +test_expect_success 'succeeds silently when using -q with invalid dates' '
These phrases may invite confusion and misunderstanding. These
dates on which you do not know where the tip of the ref was are not
necessarily "do not exist", "does not go back that far", or "invalid".
You may have pruned old entries for a long running branch. It is
just you no longer have records that go that far enough.
We would be able to tell two cases apart if we really wanted to by
looking at the oldest reflog entry. If it records a creation of the
ref, then the ref did not exist back then and the reflog does not go
back that far. It may not be a bad idea to turn the current warning
to an error in that case. And if the oldest entry knows where the
ref used to point at, then we have expired older entries. We can
continue giving the "oldest known" as before with a warning.
But that would be a separate issue.
> + ref=$(git rev-parse HEAD) &&
> + : >.git/logs/refs/test3 &&
> + git update-ref -m "message for refs/test3" refs/test3 "$ref" &&
> + git rev-parse -q --verify refs/test3@{1.year.ago} >actual 2>error &&
> + test_must_be_empty error &&
> + echo "$ref" >expect &&
> + test_cmp expect actual
> +'
> +
> test_expect_success 'no stdout output on error' '
> test -z "$(git rev-parse --verify)" &&
> test -z "$(git rev-parse --verify foo)" &&
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html