How to check repository/working tree status from a script

> On Tue, 19 May 2009, Marc Haber wrote:
> > I would like to check in a script whether there (a) are uncommitted
> > changes (as in "working tree differs from local repository")
> 
> # check working tree is not different from the index
> git diff --quiet
> # check that the index is not different from the head
> git diff --quiet --cached

> 
> On Tue, May 19, 2009 at 04:34:47PM +0100, Tony Finch wrote:
> > On Tue, 19 May 2009, Marc Haber wrote:
> > > I would like to check in a script whether there (a) are uncommitted
> > > changes (as in "working tree differs from local repository")
> > 
> > # check working tree is not different from the index
> > git diff --quiet
> > # check that the index is not different from the head
> > git diff --quiet --cached
> 
> $ git diff --quiet; echo $?
> 0
> $ git diff --quiet --cached; echo $?
> 0
> $ touch keks
> $ git diff --quiet; echo $?
> 0
> $ git diff --quiet --cached; echo $?
> 0
> $
> 
> Am I missing something?

> 
> And if what you want to know about is whether there are _new_ files you 
> might want to check, then you need a third check: 'git ls-files'. You 
> won't see it in the error code, but you can do
> 
> 	others=$(git ls-files -o --exclude-standard)
> 
> and then check it 'others' is empty or not.

> IOW, something like this:
> 
> 	# any staged changes (ready to commit)
> 	git diff --quiet --staged || echo Staged changes
> 
> 	# any changes wrt the index (not staged)
> 	others=$(git ls-files --exclude-standard -o -d -m -u)
> 	[ -z "$others" ] || echo "Other changes"
> 
> should do it.

> If you want more specificity wrt the "Other changes", you can add the "-t" 
> flag to git ls-files and parse the output to see whether the listed files 
> were just unknown (ie new files): '?', changed: 'C', removed: 'R' or need 
> to be merged: 'M'
> 
> Of course, 'git diff [--staged]' is needed if you actually want to know 
> some "deeper" patterns about _how_ things were changed. IOW, if you want 
> to know about renames/copies, you need to use 'git diff -M/C' to get that 
> kind of information.

> On Tue, 19 May 2009, Marc Haber wrote:
> > On Tue, May 19, 2009 at 04:34:47PM +0100, Tony Finch wrote:
> > > On Tue, 19 May 2009, Marc Haber wrote:
> > > > I would like to check in a script whether there (a) are uncommitted
> > > > changes (as in "working tree differs from local repository")
> > > 
> > > # check working tree is not different from the index
> > > git diff --quiet
> > > # check that the index is not different from the head
> > > git diff --quiet --cached
> > 
> > $ git diff --quiet; echo $?
> > 0
> > $ git diff --quiet --cached; echo $?
> > 0
> > $ touch keks
> > $ git diff --quiet; echo $?
> > 0
> > $ git diff --quiet --cached; echo $?
> > 0
> > $
> > 
> > Am I missing something?
> 
> If "keks" is already something you know about, then 'touch' wouldn't have 
> changed it, so diff won't show it.

> And if what you want to know about is whether there are _new_ files you 
> might want to check, then you need a third check: 'git ls-files'. You 
> won't see it in the error code, but you can do
> 
> 	others=$(git ls-files -o --exclude-standard)
> 
> and then check it 'others' is empty or not.

> On Tue, May 19, 2009 at 09:18:12AM -0700, Linus Torvalds wrote:
>> On Tue, 19 May 2009, Marc Haber wrote:
>> > On Tue, May 19, 2009 at 04:34:47PM +0100, Tony Finch wrote:
>> > > On Tue, 19 May 2009, Marc Haber wrote:
>> > > > I would like to check in a script whether there (a) are uncommitted
>> > > > changes (as in "working tree differs from local repository")
>> > >
>> > > # check working tree is not different from the index
>> > > git diff --quiet
>> > > # check that the index is not different from the head
>> > > git diff --quiet --cached
>> >
>> > $ git diff --quiet; echo $?
>> > 0
>> > $ git diff --quiet --cached; echo $?
>> > 0
>> > $ touch keks
>> > $ git diff --quiet; echo $?
>> > 0
>> > $ git diff --quiet --cached; echo $?
>> > 0
>> > $
>> >
>> > Am I missing something?
>>
>> If "keks" is already something you know about, then 'touch' wouldn't have
>> changed it, so diff won't show it.
>
> keks didn't exist previously, so the touch generated a new empty 0 byte
> file.

>
>> And if what you want to know about is whether there are _new_ files you
>> might want to check, then you need a third check: 'git ls-files'. You
>> won't see it in the error code, but you can do
>>
>>       others=$(git ls-files -o --exclude-standard)
>>
>> and then check it 'others' is empty or not.
>
> So parsing the output is both the canonical and only way to do so
> since there is no meaningful exit code? Can I assume that the
> formatting of git output is not subject to change?

> On Tue, May 19, 2009 at 09:18:12AM -0700, Linus Torvalds wrote:
>> And if what you want to know about is whether there are _new_ files you 
>> might want to check, then you need a third check: 'git ls-files'. You 
>> won't see it in the error code, but you can do
>>
>> 	others=$(git ls-files -o --exclude-standard)
>>
>> and then check it 'others' is empty or not.
> 
> So parsing the output is both the canonical and only way to do so
> since there is no meaningful exit code? Can I assume that the
> formatting of git output is not subject to change?

> See 'man git':
> 
> "Porcelain" commands are *not* for use in scripts; their output may
> change. git diff, git status, git commit, git checkout are in this category.
> 
> "Plumbing" commands are for use in scripts and their output will not
> change. git ls-files, git diff-tree, git diff-files are in this category.

> I am now looking for a solution for (b). I tried 
> 
> git log -n1 --pretty=oneline master..origin/master
> 
> but that seems to always give empty output even if a later issued git
> pull will actually pull in changes.

> On Thu, May 21, 2009 at 03:24:57PM +0200, Marc Haber wrote:
> > I am now looking for a solution for (b). I tried 
> > 
> > git log -n1 --pretty=oneline master..origin/master
> > 
> > but that seems to always give empty output even if a later issued git
> > pull will actually pull in changes.
> 
> Try running "git fetch" beforehand, which will actually update
> origin/master with what is on the remote.

> Also, if you are just checking to see whether there is any output, you
> can use the plumbing "git rev-list" instead of "git log". So something
> like:
> 
>   git fetch origin || { echo >&2 unable to fetch; exit 1; }
>   test -z "`git rev-list -1 master..origin/master`"