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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 8, 2023, 02:34 UTC
Message-ID: <xmqqmt6tzrcx.fsf@gitster.g>
In-Reply-To: <CANgJU+Vo3B=YuqgWVgiRMMiBwTFEh98O0LSJJ+ES6EM=MP4Cew@mail.gmail.com>

demerphq <demerphq@gmail.com> writes:

> 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?

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.