Determine if Git working directory is clean from a script The Next CEO of Stack OverflowHow can I pass output of one command as an argument to anotherCustom bash autocomplete for git breaks other git autocomplete featuresShell script: filter list of .pdf files, to exclude those with a .tex source fileGit “unknown revision” error when within bash scriptGit - Remove file from two branchesCan a bash script tell what directory the user is when they run the script?index.lock permissions error - .git owned by root, working tree owned by other userColorize bash output?Using git interactive rebase from within a bash script

Inexact numbers as keys in Association?

Can I calculate next year's exemptions based on this year's refund/amount owed?

Getting Stale Gas Out of a Gas Tank w/out Dropping the Tank

Small nick on power cord from an electric alarm clock, and copper wiring exposed but intact

Calculate the Mean mean of two numbers

Decide between Polyglossia and Babel for LuaLaTeX in 2019

Reference request: Grassmannian and Plucker coordinates in type B, C, D

Could a dragon use its wings to swim?

In the "Harry Potter and the Order of the Phoenix" video game, what potion is used to sabotage Umbridge's speakers?

How to Implement Deterministic Encryption Safely in .NET

Graph of the history of databases

Spaces in which all closed sets are regular closed

Are the names of these months realistic?

Help! I cannot understand this game’s notations!

How did Beeri the Hittite come up with naming his daughter Yehudit?

How to use ReplaceAll on an expression that contains a rule

Can I board the first leg of the flight without having final country's visa?

Redefining symbol midway through a document

Does higher Oxidation/ reduction potential translate to higher energy storage in battery?

Help understanding this unsettling image of Titan, Epimetheus, and Saturn's rings?

Would a grinding machine be a simple and workable propulsion system for an interplanetary spacecraft?

What does "shotgun unity" refer to here in this sentence?

What flight has the highest ratio of timezone difference to flight time?

Towers in the ocean; How deep can they be built?



Determine if Git working directory is clean from a script



The Next CEO of Stack OverflowHow can I pass output of one command as an argument to anotherCustom bash autocomplete for git breaks other git autocomplete featuresShell script: filter list of .pdf files, to exclude those with a .tex source fileGit “unknown revision” error when within bash scriptGit - Remove file from two branchesCan a bash script tell what directory the user is when they run the script?index.lock permissions error - .git owned by root, working tree owned by other userColorize bash output?Using git interactive rebase from within a bash script










61















I have a script which runs rsync with a Git working directory as destination. I want the script to have different behavior depending on if the working directory is clean (no changes to commit), or not. For instance, if the output of git status is as below, I want the script to exit:



git status
Already up-to-date.
# On branch master
nothing to commit (working directory clean)
Everything up-to-date


If the directory is not clean then I would like it to execute some more commands.



How can I check for output like the above in a shell script?










share|improve this question
























  • Would checking a status from last command help here? ($?)

    – UVV
    Sep 11 '14 at 13:27












  • Could you give more details please? What is the main idea for your script?

    – tachomi
    Sep 11 '14 at 13:29











  • @tachomi I added the context in the edit

    – brentwpeterson
    Sep 11 '14 at 13:53











  • you could just assume it's not clean and do a git reset --hard origin/branch if that is what you are going for... like if you are trying to cleanup after compiling something, etc.

    – SnakeDoc
    Sep 11 '14 at 16:42






  • 1





    @SnakeDoc You could, but I assume that the inverse case would be more common, i.e. exit if the working directory is dirty to avoid mangling local changes. Considering both case would make question more useful for future readers.

    – Thomas Nyman
    Sep 11 '14 at 16:54















61















I have a script which runs rsync with a Git working directory as destination. I want the script to have different behavior depending on if the working directory is clean (no changes to commit), or not. For instance, if the output of git status is as below, I want the script to exit:



git status
Already up-to-date.
# On branch master
nothing to commit (working directory clean)
Everything up-to-date


If the directory is not clean then I would like it to execute some more commands.



How can I check for output like the above in a shell script?










share|improve this question
























  • Would checking a status from last command help here? ($?)

    – UVV
    Sep 11 '14 at 13:27












  • Could you give more details please? What is the main idea for your script?

    – tachomi
    Sep 11 '14 at 13:29











  • @tachomi I added the context in the edit

    – brentwpeterson
    Sep 11 '14 at 13:53











  • you could just assume it's not clean and do a git reset --hard origin/branch if that is what you are going for... like if you are trying to cleanup after compiling something, etc.

    – SnakeDoc
    Sep 11 '14 at 16:42






  • 1





    @SnakeDoc You could, but I assume that the inverse case would be more common, i.e. exit if the working directory is dirty to avoid mangling local changes. Considering both case would make question more useful for future readers.

    – Thomas Nyman
    Sep 11 '14 at 16:54













61












61








61


14






I have a script which runs rsync with a Git working directory as destination. I want the script to have different behavior depending on if the working directory is clean (no changes to commit), or not. For instance, if the output of git status is as below, I want the script to exit:



git status
Already up-to-date.
# On branch master
nothing to commit (working directory clean)
Everything up-to-date


If the directory is not clean then I would like it to execute some more commands.



How can I check for output like the above in a shell script?










share|improve this question
















I have a script which runs rsync with a Git working directory as destination. I want the script to have different behavior depending on if the working directory is clean (no changes to commit), or not. For instance, if the output of git status is as below, I want the script to exit:



git status
Already up-to-date.
# On branch master
nothing to commit (working directory clean)
Everything up-to-date


If the directory is not clean then I would like it to execute some more commands.



How can I check for output like the above in a shell script?







shell-script git






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Sep 11 '14 at 16:19









Thomas Nyman

20.8k85070




20.8k85070










asked Sep 11 '14 at 13:24









brentwpetersonbrentwpeterson

8782919




8782919












  • Would checking a status from last command help here? ($?)

    – UVV
    Sep 11 '14 at 13:27












  • Could you give more details please? What is the main idea for your script?

    – tachomi
    Sep 11 '14 at 13:29











  • @tachomi I added the context in the edit

    – brentwpeterson
    Sep 11 '14 at 13:53











  • you could just assume it's not clean and do a git reset --hard origin/branch if that is what you are going for... like if you are trying to cleanup after compiling something, etc.

    – SnakeDoc
    Sep 11 '14 at 16:42






  • 1





    @SnakeDoc You could, but I assume that the inverse case would be more common, i.e. exit if the working directory is dirty to avoid mangling local changes. Considering both case would make question more useful for future readers.

    – Thomas Nyman
    Sep 11 '14 at 16:54

















  • Would checking a status from last command help here? ($?)

    – UVV
    Sep 11 '14 at 13:27












  • Could you give more details please? What is the main idea for your script?

    – tachomi
    Sep 11 '14 at 13:29











  • @tachomi I added the context in the edit

    – brentwpeterson
    Sep 11 '14 at 13:53











  • you could just assume it's not clean and do a git reset --hard origin/branch if that is what you are going for... like if you are trying to cleanup after compiling something, etc.

    – SnakeDoc
    Sep 11 '14 at 16:42






  • 1





    @SnakeDoc You could, but I assume that the inverse case would be more common, i.e. exit if the working directory is dirty to avoid mangling local changes. Considering both case would make question more useful for future readers.

    – Thomas Nyman
    Sep 11 '14 at 16:54
















Would checking a status from last command help here? ($?)

– UVV
Sep 11 '14 at 13:27






Would checking a status from last command help here? ($?)

– UVV
Sep 11 '14 at 13:27














Could you give more details please? What is the main idea for your script?

– tachomi
Sep 11 '14 at 13:29





Could you give more details please? What is the main idea for your script?

– tachomi
Sep 11 '14 at 13:29













@tachomi I added the context in the edit

– brentwpeterson
Sep 11 '14 at 13:53





@tachomi I added the context in the edit

– brentwpeterson
Sep 11 '14 at 13:53













you could just assume it's not clean and do a git reset --hard origin/branch if that is what you are going for... like if you are trying to cleanup after compiling something, etc.

– SnakeDoc
Sep 11 '14 at 16:42





you could just assume it's not clean and do a git reset --hard origin/branch if that is what you are going for... like if you are trying to cleanup after compiling something, etc.

– SnakeDoc
Sep 11 '14 at 16:42




1




1





@SnakeDoc You could, but I assume that the inverse case would be more common, i.e. exit if the working directory is dirty to avoid mangling local changes. Considering both case would make question more useful for future readers.

– Thomas Nyman
Sep 11 '14 at 16:54





@SnakeDoc You could, but I assume that the inverse case would be more common, i.e. exit if the working directory is dirty to avoid mangling local changes. Considering both case would make question more useful for future readers.

– Thomas Nyman
Sep 11 '14 at 16:54










4 Answers
4






active

oldest

votes


















108














Parsing the output of git status is a bad idea because the output is intended to be human readable, not machine-readable. There's no guarantee that the output will remain the same in future versions of Git or in differently configured environments.



UVVs comment is on the right track, but unfortunately the return code of git status doesn't change when there are uncommitted changes. It does, however, provide the --porcelain option, which causes the output of git status --porcelain to be formatted in an easy-to-parse format for scripts, and will remain stable across Git versions and regardless of user configuration.



We can use empty output of git status --porcelain as an indicator that there are no changes to be committed:



if [ -z "$(git status --porcelain)" ]; then 
# Working directory clean
else
# Uncommitted changes
fi


If we do not care about untracked files in the working directory, we can use the --untracked-files=no option to disregard those:



if [ -z "$(git status --untracked-files=no --porcelain)" ]; then 
# Working directory clean excluding untracked files
else
# Uncommitted changes in tracked files
fi


To make this more robust against conditions which actually cause git status to fail without output to stdout, we can refine the check to:



if output=$(git status --porcelain) && [ -z "$output" ]; then
# Working directory clean
else
# Uncommitted changes
fi


It's also worth noting that, although git status does not give meaningful exit code when the working directory is unclean, git diff provides the --exit-code option, which makes it behave similar to the diff utility, that is, exiting with status 1 when there were differences and 0 when none were found.



Using this, we can check for unstaged changes with:



git diff --exit-code


and staged, but not committed changes with:



git diff --cached --exit-code


Although git diff can report on untracked files in submodules via appropriate arguments to --ignore-submodules, unfortunately it seems that there is no way to have it report on untracked files in the actual working directory. If untracked files in the working directory are relevant, git status --porcelain is probably the best bet.






share|improve this answer




















  • 3





    ughhh git status --porcelain will exit with code 0 even if there are changes not staged for commit and untracked files.

    – Alexander Mills
    Aug 31 '18 at 21:19











  • I was interested in determining ahead of time if git stash would do anything (it doesn't output a useful return code). I had to add --ignore-submodules as otherwise git status would indicate submodule changes which git stash ignores.

    – Devin Lane
    Oct 27 '18 at 21:03


















12














Use:



git diff-index --quiet HEAD


The return code reflects the state of the working directory (0 = clean, 1 = dirty). Untracked files are ignored.






share|improve this answer























  • You should add link to post where did you get this!!

    – kyb
    Feb 14 '18 at 14:43






  • 6





    Returns 0 when there are untracked files in the current directory.

    – Adam Parkin
    Apr 12 '18 at 1:48






  • 1





    I don't think it's a return code, should be an exit code, I think there is a difference, return code is for bash functions, but maybe it's the same thing

    – Alexander Mills
    Aug 31 '18 at 21:20






  • 1





    If files had been touched/overwritten but are otherwise identical to the index, you need to first run git update-index --refresh before git diff-index HEAD. More info: stackoverflow.com/q/34807971/1407170

    – sffc
    Nov 1 '18 at 2:28











  • @AdamParkin I just add all files with git add . before issuing it. Usually it's the way to use it in a script

    – ceztko
    Dec 7 '18 at 13:27


















0














#!/bin/bash
echo "First arg: $1"

cd $1

bob="Already up-to-date."
echo $bob

echo $(git pull) > s.txt
cat s.txt
if [ "$(cat s.txt)" == "$bob" ]
then
echo "up"
else
echo "not up"
fi
rm -rf s.txt





share|improve this answer






























    0














    Minor extension to André's excellent answer.



    This is one way to evaluate the results and also avoid a pitfall if you're in a script which previously issued set -e.



    Untracked files are ignored.



    set +e
    git diff-index --quiet HEAD

    if [ $? == 1 ] ; then
    set -e
    GIT_MODS="dirty"
    else
    set -e
    GIT_MODS="clean"
    fi





    share|improve this answer










    New contributor




    orion elenzil is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.




















      Your Answer








      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "106"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













      draft saved

      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f155046%2fdetermine-if-git-working-directory-is-clean-from-a-script%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      108














      Parsing the output of git status is a bad idea because the output is intended to be human readable, not machine-readable. There's no guarantee that the output will remain the same in future versions of Git or in differently configured environments.



      UVVs comment is on the right track, but unfortunately the return code of git status doesn't change when there are uncommitted changes. It does, however, provide the --porcelain option, which causes the output of git status --porcelain to be formatted in an easy-to-parse format for scripts, and will remain stable across Git versions and regardless of user configuration.



      We can use empty output of git status --porcelain as an indicator that there are no changes to be committed:



      if [ -z "$(git status --porcelain)" ]; then 
      # Working directory clean
      else
      # Uncommitted changes
      fi


      If we do not care about untracked files in the working directory, we can use the --untracked-files=no option to disregard those:



      if [ -z "$(git status --untracked-files=no --porcelain)" ]; then 
      # Working directory clean excluding untracked files
      else
      # Uncommitted changes in tracked files
      fi


      To make this more robust against conditions which actually cause git status to fail without output to stdout, we can refine the check to:



      if output=$(git status --porcelain) && [ -z "$output" ]; then
      # Working directory clean
      else
      # Uncommitted changes
      fi


      It's also worth noting that, although git status does not give meaningful exit code when the working directory is unclean, git diff provides the --exit-code option, which makes it behave similar to the diff utility, that is, exiting with status 1 when there were differences and 0 when none were found.



      Using this, we can check for unstaged changes with:



      git diff --exit-code


      and staged, but not committed changes with:



      git diff --cached --exit-code


      Although git diff can report on untracked files in submodules via appropriate arguments to --ignore-submodules, unfortunately it seems that there is no way to have it report on untracked files in the actual working directory. If untracked files in the working directory are relevant, git status --porcelain is probably the best bet.






      share|improve this answer




















      • 3





        ughhh git status --porcelain will exit with code 0 even if there are changes not staged for commit and untracked files.

        – Alexander Mills
        Aug 31 '18 at 21:19











      • I was interested in determining ahead of time if git stash would do anything (it doesn't output a useful return code). I had to add --ignore-submodules as otherwise git status would indicate submodule changes which git stash ignores.

        – Devin Lane
        Oct 27 '18 at 21:03















      108














      Parsing the output of git status is a bad idea because the output is intended to be human readable, not machine-readable. There's no guarantee that the output will remain the same in future versions of Git or in differently configured environments.



      UVVs comment is on the right track, but unfortunately the return code of git status doesn't change when there are uncommitted changes. It does, however, provide the --porcelain option, which causes the output of git status --porcelain to be formatted in an easy-to-parse format for scripts, and will remain stable across Git versions and regardless of user configuration.



      We can use empty output of git status --porcelain as an indicator that there are no changes to be committed:



      if [ -z "$(git status --porcelain)" ]; then 
      # Working directory clean
      else
      # Uncommitted changes
      fi


      If we do not care about untracked files in the working directory, we can use the --untracked-files=no option to disregard those:



      if [ -z "$(git status --untracked-files=no --porcelain)" ]; then 
      # Working directory clean excluding untracked files
      else
      # Uncommitted changes in tracked files
      fi


      To make this more robust against conditions which actually cause git status to fail without output to stdout, we can refine the check to:



      if output=$(git status --porcelain) && [ -z "$output" ]; then
      # Working directory clean
      else
      # Uncommitted changes
      fi


      It's also worth noting that, although git status does not give meaningful exit code when the working directory is unclean, git diff provides the --exit-code option, which makes it behave similar to the diff utility, that is, exiting with status 1 when there were differences and 0 when none were found.



      Using this, we can check for unstaged changes with:



      git diff --exit-code


      and staged, but not committed changes with:



      git diff --cached --exit-code


      Although git diff can report on untracked files in submodules via appropriate arguments to --ignore-submodules, unfortunately it seems that there is no way to have it report on untracked files in the actual working directory. If untracked files in the working directory are relevant, git status --porcelain is probably the best bet.






      share|improve this answer




















      • 3





        ughhh git status --porcelain will exit with code 0 even if there are changes not staged for commit and untracked files.

        – Alexander Mills
        Aug 31 '18 at 21:19











      • I was interested in determining ahead of time if git stash would do anything (it doesn't output a useful return code). I had to add --ignore-submodules as otherwise git status would indicate submodule changes which git stash ignores.

        – Devin Lane
        Oct 27 '18 at 21:03













      108












      108








      108







      Parsing the output of git status is a bad idea because the output is intended to be human readable, not machine-readable. There's no guarantee that the output will remain the same in future versions of Git or in differently configured environments.



      UVVs comment is on the right track, but unfortunately the return code of git status doesn't change when there are uncommitted changes. It does, however, provide the --porcelain option, which causes the output of git status --porcelain to be formatted in an easy-to-parse format for scripts, and will remain stable across Git versions and regardless of user configuration.



      We can use empty output of git status --porcelain as an indicator that there are no changes to be committed:



      if [ -z "$(git status --porcelain)" ]; then 
      # Working directory clean
      else
      # Uncommitted changes
      fi


      If we do not care about untracked files in the working directory, we can use the --untracked-files=no option to disregard those:



      if [ -z "$(git status --untracked-files=no --porcelain)" ]; then 
      # Working directory clean excluding untracked files
      else
      # Uncommitted changes in tracked files
      fi


      To make this more robust against conditions which actually cause git status to fail without output to stdout, we can refine the check to:



      if output=$(git status --porcelain) && [ -z "$output" ]; then
      # Working directory clean
      else
      # Uncommitted changes
      fi


      It's also worth noting that, although git status does not give meaningful exit code when the working directory is unclean, git diff provides the --exit-code option, which makes it behave similar to the diff utility, that is, exiting with status 1 when there were differences and 0 when none were found.



      Using this, we can check for unstaged changes with:



      git diff --exit-code


      and staged, but not committed changes with:



      git diff --cached --exit-code


      Although git diff can report on untracked files in submodules via appropriate arguments to --ignore-submodules, unfortunately it seems that there is no way to have it report on untracked files in the actual working directory. If untracked files in the working directory are relevant, git status --porcelain is probably the best bet.






      share|improve this answer















      Parsing the output of git status is a bad idea because the output is intended to be human readable, not machine-readable. There's no guarantee that the output will remain the same in future versions of Git or in differently configured environments.



      UVVs comment is on the right track, but unfortunately the return code of git status doesn't change when there are uncommitted changes. It does, however, provide the --porcelain option, which causes the output of git status --porcelain to be formatted in an easy-to-parse format for scripts, and will remain stable across Git versions and regardless of user configuration.



      We can use empty output of git status --porcelain as an indicator that there are no changes to be committed:



      if [ -z "$(git status --porcelain)" ]; then 
      # Working directory clean
      else
      # Uncommitted changes
      fi


      If we do not care about untracked files in the working directory, we can use the --untracked-files=no option to disregard those:



      if [ -z "$(git status --untracked-files=no --porcelain)" ]; then 
      # Working directory clean excluding untracked files
      else
      # Uncommitted changes in tracked files
      fi


      To make this more robust against conditions which actually cause git status to fail without output to stdout, we can refine the check to:



      if output=$(git status --porcelain) && [ -z "$output" ]; then
      # Working directory clean
      else
      # Uncommitted changes
      fi


      It's also worth noting that, although git status does not give meaningful exit code when the working directory is unclean, git diff provides the --exit-code option, which makes it behave similar to the diff utility, that is, exiting with status 1 when there were differences and 0 when none were found.



      Using this, we can check for unstaged changes with:



      git diff --exit-code


      and staged, but not committed changes with:



      git diff --cached --exit-code


      Although git diff can report on untracked files in submodules via appropriate arguments to --ignore-submodules, unfortunately it seems that there is no way to have it report on untracked files in the actual working directory. If untracked files in the working directory are relevant, git status --porcelain is probably the best bet.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Sep 11 '14 at 16:09

























      answered Sep 11 '14 at 15:48









      Thomas NymanThomas Nyman

      20.8k85070




      20.8k85070







      • 3





        ughhh git status --porcelain will exit with code 0 even if there are changes not staged for commit and untracked files.

        – Alexander Mills
        Aug 31 '18 at 21:19











      • I was interested in determining ahead of time if git stash would do anything (it doesn't output a useful return code). I had to add --ignore-submodules as otherwise git status would indicate submodule changes which git stash ignores.

        – Devin Lane
        Oct 27 '18 at 21:03












      • 3





        ughhh git status --porcelain will exit with code 0 even if there are changes not staged for commit and untracked files.

        – Alexander Mills
        Aug 31 '18 at 21:19











      • I was interested in determining ahead of time if git stash would do anything (it doesn't output a useful return code). I had to add --ignore-submodules as otherwise git status would indicate submodule changes which git stash ignores.

        – Devin Lane
        Oct 27 '18 at 21:03







      3




      3





      ughhh git status --porcelain will exit with code 0 even if there are changes not staged for commit and untracked files.

      – Alexander Mills
      Aug 31 '18 at 21:19





      ughhh git status --porcelain will exit with code 0 even if there are changes not staged for commit and untracked files.

      – Alexander Mills
      Aug 31 '18 at 21:19













      I was interested in determining ahead of time if git stash would do anything (it doesn't output a useful return code). I had to add --ignore-submodules as otherwise git status would indicate submodule changes which git stash ignores.

      – Devin Lane
      Oct 27 '18 at 21:03





      I was interested in determining ahead of time if git stash would do anything (it doesn't output a useful return code). I had to add --ignore-submodules as otherwise git status would indicate submodule changes which git stash ignores.

      – Devin Lane
      Oct 27 '18 at 21:03













      12














      Use:



      git diff-index --quiet HEAD


      The return code reflects the state of the working directory (0 = clean, 1 = dirty). Untracked files are ignored.






      share|improve this answer























      • You should add link to post where did you get this!!

        – kyb
        Feb 14 '18 at 14:43






      • 6





        Returns 0 when there are untracked files in the current directory.

        – Adam Parkin
        Apr 12 '18 at 1:48






      • 1





        I don't think it's a return code, should be an exit code, I think there is a difference, return code is for bash functions, but maybe it's the same thing

        – Alexander Mills
        Aug 31 '18 at 21:20






      • 1





        If files had been touched/overwritten but are otherwise identical to the index, you need to first run git update-index --refresh before git diff-index HEAD. More info: stackoverflow.com/q/34807971/1407170

        – sffc
        Nov 1 '18 at 2:28











      • @AdamParkin I just add all files with git add . before issuing it. Usually it's the way to use it in a script

        – ceztko
        Dec 7 '18 at 13:27















      12














      Use:



      git diff-index --quiet HEAD


      The return code reflects the state of the working directory (0 = clean, 1 = dirty). Untracked files are ignored.






      share|improve this answer























      • You should add link to post where did you get this!!

        – kyb
        Feb 14 '18 at 14:43






      • 6





        Returns 0 when there are untracked files in the current directory.

        – Adam Parkin
        Apr 12 '18 at 1:48






      • 1





        I don't think it's a return code, should be an exit code, I think there is a difference, return code is for bash functions, but maybe it's the same thing

        – Alexander Mills
        Aug 31 '18 at 21:20






      • 1





        If files had been touched/overwritten but are otherwise identical to the index, you need to first run git update-index --refresh before git diff-index HEAD. More info: stackoverflow.com/q/34807971/1407170

        – sffc
        Nov 1 '18 at 2:28











      • @AdamParkin I just add all files with git add . before issuing it. Usually it's the way to use it in a script

        – ceztko
        Dec 7 '18 at 13:27













      12












      12








      12







      Use:



      git diff-index --quiet HEAD


      The return code reflects the state of the working directory (0 = clean, 1 = dirty). Untracked files are ignored.






      share|improve this answer













      Use:



      git diff-index --quiet HEAD


      The return code reflects the state of the working directory (0 = clean, 1 = dirty). Untracked files are ignored.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Sep 27 '17 at 5:41









      André van HerkAndré van Herk

      12912




      12912












      • You should add link to post where did you get this!!

        – kyb
        Feb 14 '18 at 14:43






      • 6





        Returns 0 when there are untracked files in the current directory.

        – Adam Parkin
        Apr 12 '18 at 1:48






      • 1





        I don't think it's a return code, should be an exit code, I think there is a difference, return code is for bash functions, but maybe it's the same thing

        – Alexander Mills
        Aug 31 '18 at 21:20






      • 1





        If files had been touched/overwritten but are otherwise identical to the index, you need to first run git update-index --refresh before git diff-index HEAD. More info: stackoverflow.com/q/34807971/1407170

        – sffc
        Nov 1 '18 at 2:28











      • @AdamParkin I just add all files with git add . before issuing it. Usually it's the way to use it in a script

        – ceztko
        Dec 7 '18 at 13:27

















      • You should add link to post where did you get this!!

        – kyb
        Feb 14 '18 at 14:43






      • 6





        Returns 0 when there are untracked files in the current directory.

        – Adam Parkin
        Apr 12 '18 at 1:48






      • 1





        I don't think it's a return code, should be an exit code, I think there is a difference, return code is for bash functions, but maybe it's the same thing

        – Alexander Mills
        Aug 31 '18 at 21:20






      • 1





        If files had been touched/overwritten but are otherwise identical to the index, you need to first run git update-index --refresh before git diff-index HEAD. More info: stackoverflow.com/q/34807971/1407170

        – sffc
        Nov 1 '18 at 2:28











      • @AdamParkin I just add all files with git add . before issuing it. Usually it's the way to use it in a script

        – ceztko
        Dec 7 '18 at 13:27
















      You should add link to post where did you get this!!

      – kyb
      Feb 14 '18 at 14:43





      You should add link to post where did you get this!!

      – kyb
      Feb 14 '18 at 14:43




      6




      6





      Returns 0 when there are untracked files in the current directory.

      – Adam Parkin
      Apr 12 '18 at 1:48





      Returns 0 when there are untracked files in the current directory.

      – Adam Parkin
      Apr 12 '18 at 1:48




      1




      1





      I don't think it's a return code, should be an exit code, I think there is a difference, return code is for bash functions, but maybe it's the same thing

      – Alexander Mills
      Aug 31 '18 at 21:20





      I don't think it's a return code, should be an exit code, I think there is a difference, return code is for bash functions, but maybe it's the same thing

      – Alexander Mills
      Aug 31 '18 at 21:20




      1




      1





      If files had been touched/overwritten but are otherwise identical to the index, you need to first run git update-index --refresh before git diff-index HEAD. More info: stackoverflow.com/q/34807971/1407170

      – sffc
      Nov 1 '18 at 2:28





      If files had been touched/overwritten but are otherwise identical to the index, you need to first run git update-index --refresh before git diff-index HEAD. More info: stackoverflow.com/q/34807971/1407170

      – sffc
      Nov 1 '18 at 2:28













      @AdamParkin I just add all files with git add . before issuing it. Usually it's the way to use it in a script

      – ceztko
      Dec 7 '18 at 13:27





      @AdamParkin I just add all files with git add . before issuing it. Usually it's the way to use it in a script

      – ceztko
      Dec 7 '18 at 13:27











      0














      #!/bin/bash
      echo "First arg: $1"

      cd $1

      bob="Already up-to-date."
      echo $bob

      echo $(git pull) > s.txt
      cat s.txt
      if [ "$(cat s.txt)" == "$bob" ]
      then
      echo "up"
      else
      echo "not up"
      fi
      rm -rf s.txt





      share|improve this answer



























        0














        #!/bin/bash
        echo "First arg: $1"

        cd $1

        bob="Already up-to-date."
        echo $bob

        echo $(git pull) > s.txt
        cat s.txt
        if [ "$(cat s.txt)" == "$bob" ]
        then
        echo "up"
        else
        echo "not up"
        fi
        rm -rf s.txt





        share|improve this answer

























          0












          0








          0







          #!/bin/bash
          echo "First arg: $1"

          cd $1

          bob="Already up-to-date."
          echo $bob

          echo $(git pull) > s.txt
          cat s.txt
          if [ "$(cat s.txt)" == "$bob" ]
          then
          echo "up"
          else
          echo "not up"
          fi
          rm -rf s.txt





          share|improve this answer













          #!/bin/bash
          echo "First arg: $1"

          cd $1

          bob="Already up-to-date."
          echo $bob

          echo $(git pull) > s.txt
          cat s.txt
          if [ "$(cat s.txt)" == "$bob" ]
          then
          echo "up"
          else
          echo "not up"
          fi
          rm -rf s.txt






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Feb 20 at 12:07









          Robert ARobert A

          1




          1





















              0














              Minor extension to André's excellent answer.



              This is one way to evaluate the results and also avoid a pitfall if you're in a script which previously issued set -e.



              Untracked files are ignored.



              set +e
              git diff-index --quiet HEAD

              if [ $? == 1 ] ; then
              set -e
              GIT_MODS="dirty"
              else
              set -e
              GIT_MODS="clean"
              fi





              share|improve this answer










              New contributor




              orion elenzil is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
              Check out our Code of Conduct.
























                0














                Minor extension to André's excellent answer.



                This is one way to evaluate the results and also avoid a pitfall if you're in a script which previously issued set -e.



                Untracked files are ignored.



                set +e
                git diff-index --quiet HEAD

                if [ $? == 1 ] ; then
                set -e
                GIT_MODS="dirty"
                else
                set -e
                GIT_MODS="clean"
                fi





                share|improve this answer










                New contributor




                orion elenzil is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.






















                  0












                  0








                  0







                  Minor extension to André's excellent answer.



                  This is one way to evaluate the results and also avoid a pitfall if you're in a script which previously issued set -e.



                  Untracked files are ignored.



                  set +e
                  git diff-index --quiet HEAD

                  if [ $? == 1 ] ; then
                  set -e
                  GIT_MODS="dirty"
                  else
                  set -e
                  GIT_MODS="clean"
                  fi





                  share|improve this answer










                  New contributor




                  orion elenzil is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.










                  Minor extension to André's excellent answer.



                  This is one way to evaluate the results and also avoid a pitfall if you're in a script which previously issued set -e.



                  Untracked files are ignored.



                  set +e
                  git diff-index --quiet HEAD

                  if [ $? == 1 ] ; then
                  set -e
                  GIT_MODS="dirty"
                  else
                  set -e
                  GIT_MODS="clean"
                  fi






                  share|improve this answer










                  New contributor




                  orion elenzil is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  share|improve this answer



                  share|improve this answer








                  edited 2 days ago





















                  New contributor




                  orion elenzil is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  answered 2 days ago









                  orion elenzilorion elenzil

                  1012




                  1012




                  New contributor




                  orion elenzil is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.





                  New contributor





                  orion elenzil is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.






                  orion elenzil is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.



























                      draft saved

                      draft discarded
















































                      Thanks for contributing an answer to Unix & Linux Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f155046%2fdetermine-if-git-working-directory-is-clean-from-a-script%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      getting Checkpoint VPN SSL Network Extender working in the command lineHow to connect to CheckPoint VPN on Ubuntu 18.04LTS?Will the Linux ( red-hat ) Open VPNC Client connect to checkpoint or nortel VPN gateways?VPN client for linux machine + support checkpoint gatewayVPN SSL Network Extender in FirefoxLinux Checkpoint SNX tool configuration issuesCheck Point - Connect under Linux - snx + OTPSNX VPN Ububuntu 18.XXUsing Checkpoint VPN SSL Network Extender CLI with certificateVPN with network manager (nm-applet) is not workingWill the Linux ( red-hat ) Open VPNC Client connect to checkpoint or nortel VPN gateways?VPN client for linux machine + support checkpoint gatewayImport VPN config files to NetworkManager from command lineTrouble connecting to VPN using network-manager, while command line worksStart a VPN connection with PPTP protocol on command linestarting a docker service daemon breaks the vpn networkCan't connect to vpn with Network-managerVPN SSL Network Extender in FirefoxUsing Checkpoint VPN SSL Network Extender CLI with certificate

                      Cannot Extend partition with GParted The 2019 Stack Overflow Developer Survey Results Are In Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) 2019 Community Moderator Election ResultsCan't increase partition size with GParted?GParted doesn't recognize the unallocated space after my current partitionWhat is the best way to add unallocated space located before to Ubuntu 12.04 partition with GParted live?I can't figure out how to extend my Arch home partition into free spaceGparted Linux Mint 18.1 issueTrying to extend but swap partition is showing as Unknown in Gparted, shows proper from fdiskRearrange partitions in gparted to extend a partitionUnable to extend partition even though unallocated space is next to it using GPartedAllocate free space to root partitiongparted: how to merge unallocated space with a partition

                      Marilyn Monroe Ny fiainany manokana | Jereo koa | Meny fitetezanafanitarana azy.