git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Ddemerphq <demerphq@gmail.com>
Date
Jan 7, 2023, 23:03 UTC
Message-ID
<CANgJU+Vo3B=YuqgWVgiRMMiBwTFEh98O0LSJJ+ES6EM=MP4Cew@mail.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/"
Next: Junio C Hamano
Message 1 of 5 in “should git rev-parse -q --verify on a range produce output?”
  1. demerphqJan 7, 2023
  2. Junio C HamanoJan 8, 2023
  3. demerphqJan 8, 2023
  4. Junio C HamanoJan 9, 2023
  5. demerphqJan 9, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.