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

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

From
Ddemerphq <demerphq@gmail.com>
Date
Jan 8, 2023, 10:45 UTC
Message-ID
<CANgJU+UeZJP=tBx7ALd8_X=b25RkAdQ1NkQpueSL-p+kpCO17Q@mail.gmail.com>
In-Reply-To
<xmqqmt6tzrcx.fsf@gitster.g>
On Sun, 8 Jan 2023 at 03:34, Junio C Hamano <gitster@pobox.com> wrote:
Show 27 quoted lines
>
> 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/"
Previous: Junio C HamanoNext: Junio C Hamano
Message 3 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.