103

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

Phrogz
  • 296,393
  • 112
  • 651
  • 745
poymode
  • 1,479
  • 3
  • 11
  • 14

6 Answers6

68

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.

chrisaycock
  • 36,470
  • 14
  • 88
  • 125
  • 4
    Trouble is, the docs for `git merge` (at 1.7.4 - http://www.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. – Matt Curtis Feb 07 '11 at 04:12
  • 12
    @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. – Cascabel Feb 07 '11 at 05:04
  • 26
    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. – pfalcon Sep 06 '14 at 09:35
  • 5
    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." – Mike Feb 16 '17 at 12:27
  • is `git rebase` the same behavior? – osexp2000 May 24 '18 at 04:04
  • @pfalcon That's because *nix apps return their status, not just error codes. Traditionally, positive status means partial failure and negative numbers mean complete failure. – shawnhcorey Oct 29 '18 at 13:52
  • @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. – mklement0 Apr 23 '19 at 05:36
  • A simple `git checkout somebranch` seems to return 1 too. – sylbru Mar 22 '21 at 09:33
65

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).

Cascabel
  • 479,068
  • 72
  • 370
  • 318
  • 4
    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. – Novice C Oct 21 '16 at 00:45
  • *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. – shawnhcorey Oct 29 '18 at 13:54
  • 5
    @shawnhcorey The problem is that git doesn't document its nonzero error codes. – Ian Kemp Feb 05 '19 at 10:18
  • You’re also going to see exit code 1 for success sometimes. – sylbru Mar 22 '21 at 09:34
13

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.

Gus Shortz
  • 1,711
  • 1
  • 15
  • 24
8

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).

allo
  • 3,955
  • 8
  • 40
  • 71
manningr
  • 139
  • 1
  • 2
6

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!)

Darren Cook
  • 27,837
  • 13
  • 117
  • 217
4

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
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250