201

The goal is to get an unambiguous status that can be evaluated in a shell command.

I tried git status but it always returns 0, even if there are items to commit.

git status
echo $?  #this is always 0

I have an idea but I think it is rather a bad idea.

if [ git status | grep -i -c "[a-z]"> 2 ];
then
 code for change...
else
  code for nothing change...
fi

any other way?


update with following solve, see Mark Longair's post

I tried this but it causes a problem.

if [ -z $(git status --porcelain) ];
then
    echo "IT IS CLEAN"
else
    echo "PLEASE COMMIT YOUR CHANGE FIRST!!!"
    echo git status
fi

I get the following error [: ??: binary operator expected

now, I am looking at the man and try the git diff.

===================code for my hope, and hope better answer======================

#if [ `git status | grep -i -c "$"` -lt 3 ];
# change to below code,although the above code is simple, but I think it is not strict logical
if [ `git diff --cached --exit-code HEAD^ > /dev/null && (git ls-files --other --exclude-standard --directory | grep -c -v '/$')` ];
then
        echo "PLEASE COMMIT YOUR CHANGE FIRST!!!"
    exit 1

else
    exit 0
fi
9nix00
  • 3,162
  • 2
  • 18
  • 25
  • 4
    In the updated section, it seems that you're not actually doing what [eckes](http://stackoverflow.com/users/520162/eckes) suggests in [his answer](http://stackoverflow.com/questions/5139290/how-to-check-if-theres-nothing-to-be-committed-in-the-current-branch/5139346#5139346) - as he says, you need to put double-quotes around the `$(git status --porcelain)`. Also, if you want to put exclamation marks in your message, you'll need to use single quotes rather than double quotes - i.e. it should be `echo 'PLEASE COMMIT YOUR CHANGE FIRST!!!'` instead – Mark Longair Feb 28 '11 at 10:13
  • 5
    as Mark says: **you need to put double quotes around the `$(git status --porcelain)`**, just as I told you! – eckes Feb 28 '11 at 10:28
  • 1
    This questions would be a lot more useful, if it didn't include parts of answers. – oberlies Nov 26 '12 at 08:58
  • @9nix00 do what you have been told and edit and fix the bug in your shell script above: BUG: if [ -z $(some command) ] FIX: if [ -z "$(some command)" ] – MarcH Feb 15 '14 at 14:13
  • possible duplicate of [How can I programmatically (in a shell script) determine whether or not there are changes?](http://stackoverflow.com/questions/28772174/how-can-i-programmatically-in-a-shell-script-determine-whether-or-not-there-ar) – jub0bs Sep 30 '15 at 11:19
  • Your second attempt, using `git status --porcelain` was nearly correct. You were just missing some double quotes around the call to `git status`. The first line should be `if [ -z "$(git status --porcelain)" ]`. The double quotes ensure that the command's output (which may contain spaces) is treated as a single argument to the `-z` test. – Chris B Jun 13 '16 at 09:59

9 Answers9

266

An alternative to testing whether the output of git status --porcelain is empty is to test each condition you care about separately. One might not always care, for example, if there are untracked files in the output of git status.

For example, to see if there are any local unstaged changes, you can look at the return code of:

git diff --exit-code

To check if there are any changes that are staged but not committed, you can use the return code of:

git diff --cached --exit-code

Finally, if you want to know about whether there are any untracked files in your working tree that aren't ignored, you can test whether the output of the following command is empty:

git ls-files --other --exclude-standard --directory

Update: You ask below whether you can change that command to exclude the directories in the output. You can exclude empty directories by adding --no-empty-directory, but to exclude all directories in that output I think you'll have to filter the output, such as with:

git ls-files --other --exclude-standard --directory | egrep -v '/$'

The -v to egrep means to only output lines that don't match the pattern, and the pattern matches any line that ends with a /.

Mark Longair
  • 385,867
  • 66
  • 394
  • 320
  • I leaned these tips and have an issue. that is , use git ls-files --other --exclude-standard --directory get the list include directories. is there someway exclude these directory? – 9nix00 Feb 28 '11 at 10:26
  • yes , this is I want . and I update my post for new script-code. I thinks yours suggest is more strict logical although more code lol... and Hope better answers appear. – 9nix00 Mar 01 '11 at 06:42
  • 3
    @albfan: it's in the [git-diff man page](http://git-scm.com/docs/git-diff): "Make the program exit with codes similar to diff(1). That is, it exits with 1 if there were differences and 0 means no differences." – Mark Longair Nov 08 '14 at 14:30
  • Just to point out, It's been there at least since 2007 [13da0fc0](https://github.com/git/git/blame/13da0fc092b8cf082eda2f16971c75903aa5aefc/diff.c#L3788), really handy for shell scripts, and fully compatible with older versions of git – albfan Nov 09 '14 at 07:53
  • Oddly failing. My test is `git diff --exit-code || echo OK` or more complex variants. I should get different answered. – Charles Merriam Apr 23 '15 at 20:09
  • 10
    `--quiet` (which implies `--exit-code`) also silences output, for those who only want the exit code. – phs Mar 05 '16 at 00:41
132

The return value of git status just tells you the exit code of git status, not if there are any modifications to be committed.

If you want a more computer-readable version of the git status output, try

git status --porcelain

See the description of git status for more information about that.

Sample use (script simply tests if git status --porcelain gives any output, no parsing needed):

if [ -n "$(git status --porcelain)" ]; then
  echo "there are changes";
else
  echo "no changes";
fi

Please note that you have to quote the string to test, i.e. the output of git status --porcelain. For more hints about test constructs, refer to the Advanced Bash Scripting Guide (Section string comparison).

Jondlm
  • 8,264
  • 2
  • 20
  • 30
eckes
  • 56,506
  • 25
  • 151
  • 189
  • hi,you give a good suggestion, I tried it, but in script ,it cause some problem , I improved it , if we use this if [ -z $(git status --porcelain) ]; it will get some error , [: ??: binary operator expected I find the manual and use this if [ -z $(git status --short) ]; this can work, thanks! – 9nix00 Feb 28 '11 at 07:52
  • sorry, there is still cause problem. when the commit is clean. use porcelain and short both ok. but when commit isn't clean. it will cause error. [: ??: binary operator expected. I think maybe we should try use base64 to encode it. let me try! downloading base64 command tools .... lol – 9nix00 Feb 28 '11 at 07:57
  • it cause problem when the commit is not clean. – 9nix00 Feb 28 '11 at 08:59
  • 1
    Great solution. For added robustness you could append `|| echo no` to the command substitution so that the workspace isn't mistakenly reported clean if `git status` fails fundamentally. Also, your code is (commendably) POSIX-compliant, but since you link to a bash guide, let me add that if you use bash's `[[ ... ]]` instead of the POSIX-compatible `[ ... ]`, you do not need to double-quote the command substitution (though it does no harm): `[[ -z $(git status --porcelain) ]]`. – mklement0 Oct 20 '14 at 04:52
  • @eckes I started a new repo a few days ago, I added a commit, I tried to write some pre-commit-hook and check what is to be committed and what you say did not work on my case. – alinsoar Mar 09 '18 at 16:24
37

If you are like me, you want to know if there are:

1) changes to existing files 2) newly added files 3) deleted files

and specifically do not want to know about 4) untracked files.

This should do it:

git status --untracked-files=no --porcelain

Here's my bash code to exit the script if the repo is clean. It uses the short version of the untracked files option:

[[ -z $(git status -uno --porcelain) ]] && echo "this branch is clean, no need to push..." && kill -SIGINT $$;
moodboom
  • 4,733
  • 2
  • 35
  • 42
  • 4
    +1 for `—untracked-files=no`; I think your test can be simplified to `[[ -z $(git status --untracked-files=no --porcelain) ]]`. `git status` shouldn't write to stderr, unless something fundamental goes wrong - and then you _do_ want to see that output. (If you wanted more robust behavior in that event, append `|| echo no` to the command substitution so that the test for cleanness still fails). String comparisons / the `-z` operator can deal with multi-line strings - no need for `tail`. – mklement0 Oct 20 '14 at 04:55
  • 2
    thanks @mklement0, even a bit shorter: `[[ -z $(git status -u no --porcelain) ]]` – moodboom Oct 21 '14 at 01:03
  • 1
    correction: my shorter version actually just checks the status on the file named "no"! Bzzt. Should be: `[[ -z $(git status -uno --porcelain) ]]` – moodboom Mar 05 '15 at 22:22
  • 2
    I appreciate the follow-up; that's a subtle bug - the lesson is that _short_ options with _optional_ arguments must have the argument appended _directly_, with no whitespace in between. How about incorporating the corrected short version directly into your answer? – mklement0 Mar 05 '15 at 22:46
9

It's possible to combine git status --porcelain with a simple grep to perform the test.

if git status --porcelain | grep .; then
    echo Repo is dirty
else
    echo Repo is clean
fi

I use this as a simple one-liner sometimes:

# pull from origin if our repo is clean
git status --porcelain | grep . || git pull origin master

Add -qs to your grep command to make it silent.

Steve Prentice
  • 21,393
  • 9
  • 50
  • 52
  • 2
    +1 for elegance; slight caveat: should `git status` fail fatally (e.g., a corrupted repo), your test will mistakenly report a _clean_ workspace. One option is to use `git status --porcelain 2>&1`, but that would 'eat' the error message if you used grep with `-q`. (Dealing with that would lose the elegance: `(git status --porcelain || echo err) | grep -q .`) – mklement0 Oct 20 '14 at 05:16
  • 1
    alternatively, one can write: `test -z "$(git status --porcelain)" || git pull origin master` – VasiliNovikov Jan 17 '18 at 14:09
6

i'd do a test on this:

git diff --quiet --cached

or this to be explicit:

git diff --quiet --exit-code --cached

where:

--exit-code

Make the program exit with codes similar to diff(1). That is, it exits with 1 if there were differences and 0 means no differences.

--quiet

Disable all output of the program. Implies --exit-code

archf
  • 81
  • 1
  • 2
5

From the git source code there is a sh script which includes the following.

require_clean_work_tree () {
    git rev-parse --verify HEAD >/dev/null || exit 1
    git update-index -q --ignore-submodules --refresh
    err=0

    if ! git diff-files --quiet --ignore-submodules
    then
        echo >&2 "Cannot $1: You have unstaged changes."
        err=1
    fi

    if ! git diff-index --cached --quiet --ignore-submodules HEAD --
    then
        if [ $err = 0 ]
        then
            echo >&2 "Cannot $1: Your index contains uncommitted changes."
        else
            echo >&2 "Additionally, your index contains uncommitted changes."
        fi
        err=1
    fi

    if [ $err = 1 ]
    then
        test -n "$2" && echo >&2 "$2"
        exit 1
    fi
}

This sniplet shows how its possible to use git diff-files and git diff-index to find out if there are any changes to previously known files. It does not however allow you to find out if a new unknown file has been added to the working tree.

Arrowmaster
  • 8,732
  • 2
  • 26
  • 25
  • this works fine except for new files . we can add this. if ! git ls-files --other --exclude-standard --directory | grep -c -v '/$' then exit 0 else echo "please commit your new file,if you don't want add it, please add it in git-ignore file." exit 1 fi – 9nix00 Mar 01 '11 at 08:43
  • Just `if [ -n "$(git ls-files --others --exclude-standard)" ]` without any additional piping or greping should be enough to detect untracked files. – Arrowmaster Mar 01 '11 at 09:10
3

I'm a bit late in the discussion, but if it's only that you need to have an exit code of 0 if git status --porcelain returns nothing and != 0 else, try this:

exit $( git status --porcelain | wc -l )

This will make the number of lines be the exit code, at the risk of getting issues when there's more than 255 lines. So

exit $( git status --porcelain | head -255 | wc -l )

will account for that ;)

Skeeve
  • 3,233
  • 2
  • 12
  • 19
2

I'm using this in a script to have:

  • 0 when everything is clean
  • 1 when there is a diff or untracked files

    [ -z "$(git status --porcelain)" ]

grosser
  • 13,530
  • 7
  • 52
  • 56
0

Not pretty, but works:

git status | grep -qF 'working directory clean' || echo "DIRTY"

Not sure whether the message is locale dependent, so maybe put a LANG=C in front.

Tilman Vogel
  • 8,221
  • 4
  • 29
  • 30