Does git return specific return error codes?

Question

Like merging errors, or rebase errors. Does it have a unique error code?

Divisive

Answer 1

I set-up a test to fail. This is what I got:

$ git merge newbranch
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.

$ echo $?
1

Git returns 0 when it merges correctly, as expected.

Persephone

Trouble is, the docs for git merge (at 1.7.4 - kernel.org/pub/software/scm/git/docs/v1.7.4/git-merge.html) only mention the return status in one place (if you use "--ff-only" and it can't do a fast-forward commit, it returns non-zero - it doesn't explicitly say what is returned if it all works or if there was a merge conflict. – Fireplug

@Matt: Git commands are very, very good about returning zero for success and non-zero (generally 1) otherwise. You can always chain commands together safely with &&; that's how their tests are implemented. – Schulte

Git is not good for returning consistent and sensible exit codes. For example, doing git commit with no changes will exit with code 1, but heck, it's not error. – Paton

From a comment in the source code of builtin/merge.c: "The backend exits with 1 when conflicts are left to be resolved, with 2 when it does not handle the given merge at all." – Vassar

is git rebase the same behavior? – Vanburen

@Paton That's because *nix apps return their status, not just error codes. Traditionally, positive status means partial failure and negative numbers mean complete failure. – Oleaster

@shawnhcorey: In POSIX-like shells (e.g., Bash), exit codes are positive 8-bit numbers, i.e., numbers between 0 and 255. 0 means success, any nonzero value indicates an error (or unsuccessful test). 1 is frequently used to indicate an error. Beyond that, there are no standardized or even conventional values that would indicate partial failure. – Abrahan

A simple git checkout somebranch seems to return 1 too. – Judges

A simple git checkout somebranch seems to return 1 too I was just bitten by this! Had a command chain git checkout mybranch && git pull and it failed to pull even though the checkout appeared to succeed! Posted a question about it which, naturally, was promptly closed by the admins. – Sate

Answer 2

In short, no. You're going to see exit code 1 for errors, and 0 for success.

From a quick grepping of the source, there are some of the expected 127 and 128 for their specific purposes (command not found, errors already reported), and a few unusual codes in a few places, but for run of the mill errors, it's all exit(1).

Schulte

This is extra annoying for debugging your commit hooks. Whats the point of even having an exit code in your git hooks if a failed commit is just going to always return 1 instead of your hook exit code. – Bain

*nix apps return a status of 0 for complete success. Other status codes are determine by the app. There are 255 other codes which meanings depend on the app. See their man pages for details. – Oleaster

@Oleaster The problem is that git doesn't document its nonzero error codes. – Woe

You’re also going to see exit code 1 for success sometimes. – Judges

Answer 3

Running git status on a non-git repo returns 128, not 1, which is helpful in quickly determining whether a git repo exists or not.

Tittle

git rev-parse --is-inside-work-tree is better – Aeolic

@Aeolic Honest question: what makes it better vs just a different way of doing the same thing? – Attaboy

@ShaunMitchell faster, explicit, more reliable + a plumbing not porcelain command – Aeolic

Answer 4

git push --delete origin a_remote_tag_name

This returns 256 if the tag doesn't exist using git version 1.8.3.1

It would be nice to have a consolidated list of specific return codes returned by each command and what they indicate. This might also help prevent changing the return code meanings (which automation scripts might rely on).

Digitalis

On Unix-like systems (Linux, macOS) the return code is a byte so it can't return 256 and has to be in the range 0 to 255. – Emad

Answer 5

Error 128, with no error message from git, could be a catch-all for "unexpected problem".

I was getting this on operations that needed to modify files under .git (e.g. "git checkout -- myfile" to revert a modified file) by a different user. (In my case "chmod -R og+w .git" fixed it; naturally, don't do that unless you understand the security implications for your case!)

Loving

Answer 6

Git 2.24 (Q4 2019) does illustrate how git commands return code.

See commit 50094ca, commit c1a6f21, commit 854b5cb, commit dd2b6b6, commit 6bd26f5, commit c6ec6da, commit f2e2fa8, commit 460609c, commit 92014b6, commit 0ab74e9, commit cb46c40, commit b562a54 (27 Aug 2019), and commit fe49814 (20 Aug 2019) by Denton Liu (Denton-L).
^{(Merged by Junio C Hamano -- gitster -- in commit 1c6fc94, 30 Sep 2019)}

t4014: stop losing return codes of git commands

Currently, there are two ways where the return codes of Git commands are lost.

The first way is when a command is in the upstream of a pipe. In a pipe, only the return code of the last command is used. Thus, all other commands will have their return codes masked.
Rewrite pipes so that there are no Git commands upstream.

The other way is when a command is in a non-assignment subshell.
The return code will be lost in favour of the surrounding command's.
Rewrite instances of this such that Git commands output to a file and surrounding commands only call subshells with non-Git commands.

So instead of writing:

git cat-file commit rebuild-1 | grep "^Side .* with .* backslash-n"

Type:

git cat-file commit rebuild-1 >actual &&
    grep "^Side .* with .* backslash-n" actual

Merat