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. -- 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