aboutsummaryrefslogtreecommitdiff
path: root/versioncmp.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2015-10-28 18:44:21 -0400
committerJunio C Hamano <gitster@pobox.com>2015-10-29 12:10:23 -0700
commite34f80278e920e53b69016c7cecb24e4621e4564 (patch)
tree74ef9ebff60018e37116154b565a6fb87c20c69b /versioncmp.c
parent282616c72d1d08a77ca4fe1186cb708c38408d87 (diff)
downloadgit-e34f80278e920e53b69016c7cecb24e4621e4564.tar.gz
git-e34f80278e920e53b69016c7cecb24e4621e4564.tar.xz
merge-file: clamp exit code to maximum 127
Git-merge-file is documented to return one of three exit codes: - zero means the merge was successful - a negative number means an error occurred - a positive number indicates the number of conflicts Unfortunately, this all gets stuffed into an 8-bit return code. Which means that if you have 256 conflicts, this wraps to zero, and the merge appears to succeed (and commits a blob full of conflict-marker cruft!). This patch clamps the return value to a maximum of 127, which we should be able to safely represent everywhere. This also leaves 128-255 for other values. Shells (and some parts of git) will typically represent signal death as 128 plus the signal number. And negative values are typically coerced to an 8-bit unsigned value (so "return -1" ends up as 255). Technically negative returns have the same problem (e.g., "-256" wraps back to 0), but this is not a problem in practice, as the only negative value we use is "-1". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'versioncmp.c')
0 files changed, 0 insertions, 0 deletions