When we try to exec a git sub-command, we pass along the status code from run_command(). But that may return -1 if we ran into an error with pipe() or execve(). This tends to work (and end up as 255 due to twos-complement wraparound and truncation), but in general it's probably a good idea to avoid negative exit codes for portability. We can easily translate to the normal generic "128" code we get when syscalls cause us to die. Signed-off-by: Jeff King <peff@xxxxxxxx> --- I know that negative exit codes were a problem once upon a time on Windows, but I think that is fine since 47e3de0e79 (MinGW: truncate exit()'s argument to lowest 8 bits, 2009-07-05). Still, I think it's a weird portability thing that we are better off avoiding (and certainly I wouldn't be surprised if some callers assume everything >128 is a signal). git.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/git.c b/git.c index d0e04d5c97..bc2f2a7ec9 100644 --- a/git.c +++ b/git.c @@ -593,12 +593,16 @@ static void execv_dashed_external(const char **argv) trace_argv_printf(cmd.args.argv, "trace: exec:"); /* - * if we fail because the command is not found, it is - * OK to return. Otherwise, we just pass along the status code. + * If we fail because the command is not found, it is + * OK to return. Otherwise, we just pass along the status code, + * or our usual generic code if we were not even able to exec + * the program. */ status = run_command(&cmd); - if (status >= 0 || errno != ENOENT) + if (status >= 0) exit(status); + else if (errno != ENOENT) + exit(128); } static int run_argv(int *argcp, const char ***argv) -- 2.11.0.527.gfef230ca76