git ls-files unreliable?

Gabor Gombas· Apr 2, 2010, 18:08 UTC · lore

Hi,

I want to verify from a script that the working directory is clean. Some time ago Linus suggested to use "git diff --quiet --cached" followed by "git ls-files --exclude-standard -o -d -m -u". But:

$ git status # On branch git_workdir_check # Your branch is ahead of 'origin/master' by 1 commit. # # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: ../../../test # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working # directory) # # modified: ../../../test # $ git ls-files --exclude-standard -o -d -m -u $ echo $? 0

So there _were_ uncommitted changes, "git status" showed them, but "git ls-files" did not. Unstaging the staged changes did not help, changing a different file did not help. Tried git versions 1.5.4.2 and 1.7.0-rc2, both showed the same behavior.

When I did a "commit" and changed a file after that, then ls-files
started to take notice. I don't know how to reproduce the state shown
above. But this means that I cannot rely on "git ls-files" to check if
the working directory is clean; so what should I use instead?
Restriction: any solutions must work with git versions as old as 1.5.4.

Gabor

Alex Riesen· Apr 2, 2010, 20:54 UTC · re: Gabor Gombas · lore

Re: git ls-files unreliable?

On Fri, Apr 2, 2010 at 20:08, Gabor Gombas <gombasg@digikabel.hu> wrote:

> Hi,
>
> I want to verify from a script that the working directory is clean. Some
> time ago Linus suggested to use "git diff --quiet --cached" followed by

In your script, you seem to have missed the "diff" part

Show 18 quoted lines

> "git ls-files --exclude-standard -o -d -m -u". But:
>
> $ git status
> # On branch git_workdir_check
> # Your branch is ahead of 'origin/master' by 1 commit.
> #
> # Changes to be committed:
> #   (use "git reset HEAD <file>..." to unstage)
> #
> #       modified:   ../../../test
> #
> # Changed but not updated:
> #   (use "git add <file>..." to update what will be committed)
> #   (use "git checkout -- <file>..." to discard changes in working
> #   directory)
> #
> #       modified:   ../../../test
> #

Here. Were is your call to "git diff --cached"?

> $ git ls-files --exclude-standard -o -d -m -u
> $ echo $?
> 0

This is correct.

> So there _were_ uncommitted changes, "git status" showed them, but "git
> ls-files" did not.

Because it is not supposed to. The command "git ls-files" just shows the files not known to git. You have to parse the output. Not that it is complicated in this particular case: you consider the workdir unclean on any output.

> Restriction: any solutions must work with git versions as old as 1.5.4.

It probably will, but please check "git diff --cached" exit code. It may be always 0, in which case you'll have to fallback to output parsing here too.