Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> We also restrict the list to those that match any
> disambiguation hint. E.g.:
>
>   $ git rev-parse b2e1:foo
>   error: short SHA1 b2e1 is ambiguous
>   hint: The candidates are:
>   hint:   b2e1196 tag v2.8.0-rc1
>   hint:   b2e11d1 tree
>   hint:   b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options'
>   fatal: Invalid object name 'b2e1'.
>
> does not bother reporting the blobs, because they cannot
> work as a treeish.

That's a nice touch, and it even comes free--how wonderful.

It somehow felt strange to have an expensive (compared to no-op,
anyway) loop whose only externally visible effect is to call
advise(), but there does not appear to be a way to even disable this
advise() output, so it probably is OK, I guess.

>  
> +test_expect_success C_LOCALE_OUTPUT 'ambiguity hints' '
> +	test_must_fail git rev-parse 000000000 2>stderr &&
> +	grep ^hint: stderr >hints &&
> +	# 16 candidates, plus one intro line
> +	test_line_count = 17 hints
> +'
> +
> +test_expect_success C_LOCALE_OUTPUT 'ambiguity hints respect type' '
> +	test_must_fail git rev-parse 000000000^{commit} 2>stderr &&
> +	grep ^hint: stderr >hints &&
> +	# 5 commits, 1 tag (which is a commitish), plus intro line
> +	test_line_count = 7 hints
> +'
> +
> +test_expect_success C_LOCALE_OUTPUT 'failed type-selector still shows hint' '
> +	# these two blobs share the same prefix "ee3d", but neither
> +	# will pass for a commit
> +	echo 851 | git hash-object --stdin -w &&
> +	echo 872 | git hash-object --stdin -w &&
> +	test_must_fail git rev-parse ee3d^{commit} 2>stderr &&
> +	grep ^hint: stderr >hints &&
> +	test_line_count = 3 hints
> +'
> +
>  test_done