Determine if Git working directory is clean from a script
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
add a comment |
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
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 agit 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
add a comment |
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
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
shell-script git
edited Sep 11 '14 at 16:19
Thomas Nyman
20.6k85070
20.6k85070
asked Sep 11 '14 at 13:24
brentwpetersonbrentwpeterson
8532918
8532918
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 agit 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
add a comment |
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 agit 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
add a comment |
3 Answers
3
active
oldest
votes
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.
2
ughhhgit 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 ifgit stash
would do anything (it doesn't output a useful return code). I had to add--ignore-submodules
as otherwisegit status
would indicate submodule changes whichgit stash
ignores.
– Devin Lane
Oct 27 '18 at 21:03
add a comment |
Use:
git diff-index --quiet HEAD
The return code reflects the state of the working directory (0 = clean, 1 = dirty). Untracked files are ignored.
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 rungit update-index --refresh
beforegit diff-index HEAD
. More info: stackoverflow.com/q/34807971/1407170
– sffc
Nov 1 '18 at 2:28
@AdamParkin I just add all files withgit add .
before issuing it. Usually it's the way to use it in a script
– ceztko
Dec 7 '18 at 13:27
add a comment |
#!/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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
2
ughhhgit 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 ifgit stash
would do anything (it doesn't output a useful return code). I had to add--ignore-submodules
as otherwisegit status
would indicate submodule changes whichgit stash
ignores.
– Devin Lane
Oct 27 '18 at 21:03
add a comment |
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.
2
ughhhgit 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 ifgit stash
would do anything (it doesn't output a useful return code). I had to add--ignore-submodules
as otherwisegit status
would indicate submodule changes whichgit stash
ignores.
– Devin Lane
Oct 27 '18 at 21:03
add a comment |
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.
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.
edited Sep 11 '14 at 16:09
answered Sep 11 '14 at 15:48
Thomas NymanThomas Nyman
20.6k85070
20.6k85070
2
ughhhgit 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 ifgit stash
would do anything (it doesn't output a useful return code). I had to add--ignore-submodules
as otherwisegit status
would indicate submodule changes whichgit stash
ignores.
– Devin Lane
Oct 27 '18 at 21:03
add a comment |
2
ughhhgit 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 ifgit stash
would do anything (it doesn't output a useful return code). I had to add--ignore-submodules
as otherwisegit status
would indicate submodule changes whichgit stash
ignores.
– Devin Lane
Oct 27 '18 at 21:03
2
2
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
add a comment |
Use:
git diff-index --quiet HEAD
The return code reflects the state of the working directory (0 = clean, 1 = dirty). Untracked files are ignored.
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 rungit update-index --refresh
beforegit diff-index HEAD
. More info: stackoverflow.com/q/34807971/1407170
– sffc
Nov 1 '18 at 2:28
@AdamParkin I just add all files withgit add .
before issuing it. Usually it's the way to use it in a script
– ceztko
Dec 7 '18 at 13:27
add a comment |
Use:
git diff-index --quiet HEAD
The return code reflects the state of the working directory (0 = clean, 1 = dirty). Untracked files are ignored.
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 rungit update-index --refresh
beforegit diff-index HEAD
. More info: stackoverflow.com/q/34807971/1407170
– sffc
Nov 1 '18 at 2:28
@AdamParkin I just add all files withgit add .
before issuing it. Usually it's the way to use it in a script
– ceztko
Dec 7 '18 at 13:27
add a comment |
Use:
git diff-index --quiet HEAD
The return code reflects the state of the working directory (0 = clean, 1 = dirty). Untracked files are ignored.
Use:
git diff-index --quiet HEAD
The return code reflects the state of the working directory (0 = clean, 1 = dirty). Untracked files are ignored.
answered Sep 27 '17 at 5:41
André van HerkAndré van Herk
11912
11912
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 rungit update-index --refresh
beforegit diff-index HEAD
. More info: stackoverflow.com/q/34807971/1407170
– sffc
Nov 1 '18 at 2:28
@AdamParkin I just add all files withgit add .
before issuing it. Usually it's the way to use it in a script
– ceztko
Dec 7 '18 at 13:27
add a comment |
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 rungit update-index --refresh
beforegit diff-index HEAD
. More info: stackoverflow.com/q/34807971/1407170
– sffc
Nov 1 '18 at 2:28
@AdamParkin I just add all files withgit 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
add a comment |
#!/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
add a comment |
#!/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
add a comment |
#!/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
#!/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
answered Feb 20 at 12:07
Robert ARobert A
1
1
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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