Larry D'Anna [off-list ref] writes:
The script calling git push --dry-run --porcelain can see clearly from the
output that the updates will be rejected. However, it will probably need to
distinguish this condition from the push failing for other reasons, such as the
remote not being reachable.
I am not sure about this reasoning. If you are telling the script writers
to decide what happened by reading from the output, shouldn't the program
say "I fail because I cannot reach the other side" to its standard output
so that the script can read it as well?
Having said that, I don't think it matters either way. If a script wants
to know if push would fully succeed or not, it will run without
--porcelain (perhaps while discarding the standard error) and check the
status. Even without this patch, if a script runs with --porcelain and
gets non-zero status, it can inspect the output and if it got rejection,
that is a sure sign that it at least reached the other end to get enough
information to decide that it will be rejected, no?
* Junio C Hamano (gitster@pobox.com) [100208 15:59]:
Larry D'Anna [off-list ref] writes:
quoted
The script calling git push --dry-run --porcelain can see clearly from the
output that the updates will be rejected. However, it will probably need to
distinguish this condition from the push failing for other reasons, such as the
remote not being reachable.
I am not sure about this reasoning. If you are telling the script writers
to decide what happened by reading from the output, shouldn't the program
say "I fail because I cannot reach the other side" to its standard output
so that the script can read it as well?
Wouldn't that just complicate life for the script writer? If you send such
messages to the standard output, the script would have to include logic to
distinguish error messages from the rest of the output. If you send them to the
standard error then the script knows exactly where to find them.
Having said that, I don't think it matters either way. If a script wants
to know if push would fully succeed or not, it will run without
--porcelain (perhaps while discarding the standard error) and check the
status. Even without this patch, if a script runs with --porcelain and
gets non-zero status, it can inspect the output and if it got rejection,
that is a sure sign that it at least reached the other end to get enough
information to decide that it will be rejected, no?
Yes, it's a sure sign that it reached the other side, but how does the script
know nothing else went wrong? What if a malloc failed? OK that's a bit far
fetched, but it's really, really nice to be able to get an unambiguous status
bit out of a command so you know if the requested operation succeeded or not.
Without this patch, a script calling git push --porcelain --dry-run has no way
of distinguishing these two situations
1) "git push" would try to push a ref that would get rejected, but everything
else is fine.
2) "git push" would try to push a ref that would get rejected, and also some
unknown type of error occurred that this script has no idea how to handle.
--larry