On Tue, Apr 27 2021, Han-Wen Nienhuys via GitGitGadget wrote:
> From: Han-Wen Nienhuys <hanwen@xxxxxxxxxx>
>
> Signed-off-by: Han-Wen Nienhuys <hanwen@xxxxxxxxxx>
> ---
> t/t9300-fast-import.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
> index 5c47ac4465cb..1aea943bef72 100755
> --- a/t/t9300-fast-import.sh
> +++ b/t/t9300-fast-import.sh
> @@ -392,7 +392,7 @@ test_expect_success 'B: accept branch name "TEMP_TAG"' '
> git gc
> git prune" &&
> git fast-import <input &&
> - test -f .git/TEMP_TAG &&
> + test $(test-tool ref-store main resolve-ref TEMP_TAG 0 | cut -f1 -d " " ) != "$ZERO_OID" &&
> test $(git rev-parse main) = $(git rev-parse TEMP_TAG^)
> '
We have resolve-ref and verify-ref in the helper, why not a few-line
"exists-ref" or similar instead of needing to parse this out with
shell/cut/test?
I haven't tested, but in resolve-ref we do this:
printf("%s %s 0x%x\n", oid_to_hex(&oid), ref ? ref : "(null)", flags);
return ref ? 0 : 1;
So re my earlier question about "ref" being NULL or not, isn't this
going to be reflected by the exit code of resolve-ref already? I.e. any
"exists-ref" would just be a convenience wrapper equivalent to a
"--quiet" flag for resolve-ref, no?
