Timo Funke <timoses@xxxxxxx> writes: >> container# git diff-index --quiet HEAD -- ; echo $? > 1 >> container# git status > On branch master > nothing to commit, working tree clean >> container# git diff-index --quiet HEAD -- ; echo $? > 0 This is unfortunately very much expected and doubly unfortunately not very well documented. Patches to update documentation is very much welcomed, but such a patch cannot be written in void, so let's explain what is going on. To detect paths that have not been modified quickly, Git uses the mechanism called "cached stat data" in the index. Among the cached stat data is the timestamp of the last modification of each file. By noting that the fact that the last time it checked, the contents in the file on the filesystem hasn't been modified, together with the file timestamp observed at the time of such a check, the next time somebody asks "please compute 'git diff'", Git can notice that the timestamp of the working tree file hasn't changed and say "no, there is no change" without looking at the contents. Now, when the file on the filesystem is "touched" in a way that its timestamp gets updated without changing the contents (hence, if there weren't the above optimization, diff would have said "no change"), Git will think there is a change in the file. There are two levels of Git subcommands. Porcelain commands, like "git diff", are end-user facing and are optimized more for usability than performance. "git diff --quiet HEAD --" in the above scenario WILL notice that there is no change in the contents after all and exit with 0 (unless diff.autoRefreshIndex configuration is set to false). The way they do so is by refreshing the "cached stat data" automatically before using, and that operation is called "refreshing the index" (hence the configuration variable name to disable it). On the other hand, plumbing commands, like "git diff-files" and "git diff-index", are designed to be used in scripts, number of times, and do not want to pay the cost of refreshing the index always before working. The correct way to use them in a repository whose current state you do not know about is to first "refresh the index" by running the command to do so, e.g. "git update-index --refresh" before doing anything else. If you were to run "git diff-files" and "git diff-index HEAD" in a row in order to compute what "git status" would give you, for example, you do not need to and want to pay the cost of refreshing the index twice. You run "git update-index --refresh" once, and then run "git diff-files". Doing so would not change the contents of the working tree files, so you do not have to refresh the index again after that, before running "git diff-index HEAD". That is why these plumbing commands do not refresh the index themselves. They expect you to be refreshing the index before you call them. "git status" is one of the commands (as a Porcelain) that refreshes the index automatically, so it is very much understandable that the same "diff-index --quiet" behaves differently after running it once and until you touch/smudge the working tree files.
