should git rev-parse -q --verify on a range produce output?

Hi all,

I was curious if it is a bug that `rev-parse -q --verify` produces output for a commit range, and only reveals it is supposed to be used with a single commit as an error message? When combined with -q it make it seem like it has silently worked if you aren't careful to check $? afterwards. (Which obviously some script wasn't or I wouldn't be posting this. :-)

For example:

git rev-parse --verify -q HEAD^..HEAD; echo $? 869400a03fff1b3dcff82f3357d37ab506af2788 ^13073008cfc15016d862c630d56323bb7c9d775e 1

"looks" like it has worked, producing two output refs, but as it shows the exit code is 1. We have also seen it output a single line from a range, when the entire range wasn't cloned.

It seems weird that it produces output at all in this case. Shouldn't it see that it is a range and exit with a nonzero exit code immediately? The docs say:

       --verify
           Verify that exactly one parameter is provided, and that it
can be turned into a raw 20-byte SHA-1 that
           can be used to access the object database. If so, emit it
to the standard output; otherwise, error out.
           ...
       -q, --quiet
           Only meaningful in --verify mode. Do not output an error
message if the first argument is not a valid
           object name; instead exit with non-zero status silently.
SHA-1s for valid object names are printed to
           stdout on success.

It seems to me that the second sentence from --verify indicates that it should not produce output from a range at all, although I guess the exact meaning of "error out" is ambiguous, and the last sentence of the --quiet documentation is not incompatible with it also producing output when it fails, but it seems like if this is expected behavior it should be documented more explicitly. Which makes me think it is a bug. :-)

I am testing with git version 2.25.1 but this was encountered on GitHub with whatever git they used as well. (We noticed this in a CI pipeline using a shallow clone.)

cheers Yves

demerphq <demerphq@gmail.com> writes:

I know that the original scenario that the combination of "--verify" and "--quiet" was invented for was "I have a string that ought to resolve to a single object name, but the object may be missing", and

	if git cat-file -e "$name" 2>/dev/null
	then
		rawname=$(git rev-parse --verify "$name")
		true
	else
		false
	fi &&
	... do something that uses $rawname here ...
	
is a mouthful.  It becomes easier to use if we can say

	rawname=$(git rev-parse -q --verify "$name") &&
	... do something that uses $rawname here ...

I do not think the behaviour in usecase outside that was carefully designed to the details.

On Sun, 8 Jan 2023 at 03:34, Junio C Hamano <gitster@pobox.com> wrote:

Is this something you think should be fixed? I would give it a go if there was some direction on what it should do in this case. Just error early and produce no output?

BTW, the weird behavior of it is documented here: https://github.com/Perl/perl5/pull/20657

We have some tooling which we use to generate lists of contributors for each release from the git commits, and we test this code each build on specific known commit ranges. We noticed this because some of our tests run in shallow clones and we were using rev-parse to disable the test if the clone didnt have the right commit range. But it was failing sometimes when it didnt have the complete range and we were "doing it wrong" by not checking the error code and just checking to see if it output anything.

cheers, Yves

demerphq <demerphq@gmail.com> writes:

I do not mind if the error case gets changed to behave differently, as long as the updated behaviour is something everybody thinks an improvement over the current behaviour. I do not offhand know what the "fixed" behaviour should be.

I do not mind if nothing changed and documentation gets updated to reduce end-user confusion, either.

Thanks.

On Mon, 9 Jan 2023 at 04:51, Junio C Hamano <gitster@pobox.com> wrote:

Ok, I'll wait a bit to see if someone can suggest a good alternative behavior, and if nobody does ill write a doc patch.

Cheers! Yves