On Sun, 8 Jan 2023 at 03:34, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > demerphq <demerphq@xxxxxxxxx> 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/"
