What are cherry-pick's exit codes?
- From
Sean Allred <allred.sean@gmail.com>
- Date
- Dec 1, 2022, 06:39 UTC
- Message-ID
- <878rjry5a7.fsf@gmail.com>
Hi folks,
We're developing some internal tooling wrapping git-cherry-pick and need to be able to distinguish its different error codes. Problem is: these exit codes don't seem to be documented in git-cherry-pick.txt.
Looking at the source, I found myself down the rabbit-hole very quickly. I'm not too familiar with the coding patterns quite yet -- but I'm pretty sure I eventually found myself redirected to git-commit in one case. At that point, I thought it better to ask here.
I'd like to document these exit codes in the manpage and I'm more than happy to submit the patch, but I thought I'd confirm my understanding first since it's based purely on reading the cherry-pick tests:
Exit code:
- 0: success, sequencer complete -- no conflicts
- 1: 'success', sequencer incomplete -- conflicts encountered
- 127: fatal -- lots of reasons -- I'm guessing this is value for the
'return -1' and 'return error(...)' statements speckled throughout
the code, but it's been a long time since I cared about two's
complement so I may be wrong here. - 128: fatal -- sequence is interrupted, possibly due to some other
fatal error, e.g., 'commit doesn't exist' or 'mainline parent number
doesn't exist' - 129: fatal -- there was nothing to cherry-pick at all (e.g. empty
range)I'm reasonably confident about 0/1 just anecdotally -- I'm less sure about everything else.
Obviously the actual text put in the manpage should be friendlier and possibly vaguer for clarity (paradoxical, perhaps, but it seems more direct to say '0 for success, 1 for conflicts, and anything else is a fatal error'), but I wanted to make sure that I have an actually- accurate understanding rather than something only surface-level.
Two questions:
1. Are the exit codes actually documented somewhere already that
should simply be linked from git-cherry-pick.txt?2. If not, is the above listing the exit codes accurate and complete?
Thanks!
-- Sean Allred