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

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

[demerphq]

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


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

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

[Junio C Hamano]

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.

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

[demerphq]

On Sun, 8 Jan 2023 at 03:34, Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.

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

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

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

[Junio C Hamano]

demerphq <demerphq@gmail.com> writes:

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

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.

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

[demerphq]

On Mon, 9 Jan 2023 at 04:51, Junio C Hamano <gitster@pobox.com> wrote:
>
> demerphq <demerphq@gmail.com> writes:
>
> > 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?
>
> 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.

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

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"