Junio C Hamano <gitster@xxxxxxxxx> writes: > Kacper Kornet <draenog@xxxxxxxxxxxxx> writes: > >> git-ls-remote behaves differently then git-show-ref when it cannot find >> any matching refs. While the latter returns non zero exit code in this >> case, the former always returns 0. Is there any specific reason for this >> behaviour? > > There is no specific reason other than "they happened to be implemented > like so". These commands have always behaved that way and people are > relying on their exit status, so unless there is a compelling reason, they > will not change. > > It is just a matter of opinion to consider that it is an error condition > or just a normal case to see an empty set for a "List 'em and filter with > these criteria" request. Outside git, "find /there -name no-such-file" > exits with zero status, while "grep no-such-pattern file" exits with > non-zero status. > > You can rely on your knowledge of the commands and write your tests like > this: > > test $(git ls-remote $there $pattern | wc -l) != 0 || die "none" > git show-ref -q $pattern || die "none" > > Alternatively, you can defend yourself against the next person who asks > the same question by writing the last one as: > > test $(git show-ref $pattern | wc -l) != 0 || die "none" > > Either would work. Having said all that, I would not oppose if you want to teach ls-remote an option, e.g. --exit-code, to tell it to indicate if it found any ref with its exit status. You need to be careful when picking what code to use so that the caller can tell if the error was because there was no network connection or there was nothing to be listed, though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html