On Wed, Sep 02, 2009 at 06:27:15PM +0100, James Spencer wrote: > $ git diff-files > $ touch test > $ git diff-files > :100644 100644 9daeafb9864cf43055ae93beb0afd6c7d144bfa4 > 0000000000000000000000000000000000000000 M test > $ git diff > $ git diff-files > $ > > I don't understand why git diff-files reports a file is changed when > that file is touched nor why running git diff changes this to (what I > think is) the correct behaviour. Git uses the stat information of a file to know whether what we have cached in the index is up-to-date or not. So in the first diff-files, we don't even have to look at the contents of "test"; we see that it hasn't changed since the last time we looked at the contents, and that its sha-1 matches what's in the index, so there is no diff. By running "touch", you have changed the stat information, so we believe there may be a difference. But we don't actually know what's _in_ the new side, so we just print the null sha1 instead of the actual sha1 contents. Diff-files _could_ refresh the cache each time it runs, but we intentionally do not do that. Doing so is a little bit expensive, and because diff-files is intended as a low-level tool for scripts, we give the script the flexibility (and responsibility) of refreshing the cache when it wants to. So you could do: $ git update-index --refresh $ git diff-files and get clean output. You see different behavior from "git diff" because it is meant for user consumption and therefore refreshes the cache automatically at the beginning of every run. -Peff -- 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