Serguey Asael Shinder: A command's exit code is part of its interface, even for --help
Git 2.56.0 contains a small line in its release notes: option parsing in most subcommands now exits with status 0 instead of 129 when the user asks for help directly with -h or --help, "aligning with standard Unix convention". It is the right change. Asking for help is not an error, and a program that treats it as one makes every wrapper script handle a false failure.
It is still a behaviour change, and I think it is worth being deliberate about why.
A command line tool has two interfaces. The one people write down is the text: flags, arguments, the format of the output. The one people depend on without writing it down is the exit status. Continuous integration steps branch on it, shell scripts chain on it with &&, and monitoring turns a non-zero value into a page. Somewhere there is almost certainly a script that ran git something -h, expected 129, and treated that as the normal outcome. After the upgrade it sees 0, and whether that breaks anything depends on how carefully it was written.
The same pattern appears with any value a program emits that was never formally promised: the order of lines in output, the wording of an error message that a script greps for, the time a command takes. Consumers find these values and build on them, and the program's authors learn which ones matter only when they change them.
Three habits have helped me on both sides of this.
When I write a tool, I document the exit codes the same way I document flags, including the unexciting ones, and I treat a change to them as a change to be announced, not a refactor.
When I consume a tool, I check exit status against the documented set, not against whatever number I observed once. If the documentation does not define it, I check for success or failure only, and I do not branch on the specific non-zero value.
When I upgrade, I read release notes for anything that changes what a command returns or prints, not only for new features. The Git team put this one in the notes. Many projects do not, and then the only record of the change is the build that turned red the morning after.