git ls-files unreliable?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]