# should git rev-parse -q --verify on a range produce output? 5 messages from 2023-01-07 to 2023-01-09. Participants: demerphq, Junio C Hamano. Thread: https://gitlist.dev/t/59047 ## demerphq, 2023-01-07 23:03 Subject: should git rev-parse -q --verify on a range produce output? Message-ID: URL: https://gitlist.dev/e/CANgJU%2BVo3B%3DYuqgWVgiRMMiBwTFEh98O0LSJJ%2BES6EM%3DMP4Cew%40mail.gmail.com ``` 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/" ``` ## Junio C Hamano, 2023-01-08 02:34 Subject: Re: should git rev-parse -q --verify on a range produce output? Message-ID: URL: https://gitlist.dev/e/xmqqmt6tzrcx.fsf%40gitster.g In-Reply-To: ``` demerphq 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. ``` ## demerphq, 2023-01-08 10:45 Subject: Re: should git rev-parse -q --verify on a range produce output? Message-ID: URL: https://gitlist.dev/e/CANgJU%2BUeZJP%3DtBx7ALd8_X%3Db25RkAdQ1NkQpueSL-p%2BkpCO17Q%40mail.gmail.com In-Reply-To: ``` On Sun, 8 Jan 2023 at 03:34, Junio C Hamano wrote: > > demerphq 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/" ``` ## Junio C Hamano, 2023-01-09 03:51 Subject: Re: should git rev-parse -q --verify on a range produce output? Message-ID: URL: https://gitlist.dev/e/xmqqpmbowek7.fsf%40gitster.g In-Reply-To: ``` demerphq 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. ``` ## demerphq, 2023-01-09 09:04 Subject: Re: should git rev-parse -q --verify on a range produce output? Message-ID: URL: https://gitlist.dev/e/CANgJU%2BVsAZ6Dz05ZFRQfGLgti7WssdYqGaEYEQuACoCdN%2Bnvew%40mail.gmail.com In-Reply-To: ``` On Mon, 9 Jan 2023 at 04:51, Junio C Hamano wrote: > > demerphq 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/" ```