diff-files inconsistency with touched files

diff-files inconsistency with touched files

[James Spencer]

Hi,

I am puzzled by the following behaviour:

$ git --version
git version 1.6.4.2
$ 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.

Thanks in advance,

    --James

Re: diff-files inconsistency with touched files

[Jeff King]

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

Re: diff-files inconsistency with touched files

[James Spencer]

Jeff King wrote:
> 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

Thanks for your help!

    --James