Re: [PATCH] run-command: simplify wait_or_whine

>> commit 709ca730f8e093005cc882bfb86c0ca9c83d345b
>> Author: Jeff King <peff@peff.net>
>> Date:   Sat Jan 5 09:49:49 2013 -0500
>>
>>     run-command: encode signal death as a positive integer
>>
>>     When a sub-command dies due to a signal, we encode the
>>     signal number into the numeric exit status as "signal -
>>     128". This is easy to identify (versus a regular positive
>>     error code), and when cast to an unsigned integer (e.g., by
>>     feeding it to exit), matches what a POSIX shell would return
>>     when reporting a signal death in $? or through its own exit
>>     code.
>>
>>     So we have a negative value inside the code, but once it
>>     passes across an exit() barrier, it looks positive (and any
>>     code we receive from a sub-shell will have the positive
>>     form). E.g., death by SIGPIPE (signal 13) will look like
>>     -115 to us in inside git, but will end up as 141 when we
>>     call exit() with it. And a program killed by SIGPIPE but run
>>     via the shell will come to us with an exit code of 141.
>
> Your patch changes the error code that is propagated via exit() in this
> case. We cannot know "nobody is checking for the specific code", because
> the list of callers is every shell script or program which execs git.
> Some of them do care about the exit code. I can give an example of a
> case I have that cares, but I do not think it is even important. The
> point is that we would be regressing an existing interface, and cannot
> know who is broken by it.