Re: Git diff-file bug?

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

 



On Fri, Sep 28, 2012 at 07:55:10PM +0100, Scott Batchelor wrote:

> I'm fairly new to git and am witnessing some strange behavior with git
> that I suspect may be a bug. Can anyone set my mind at rest.

It's not a bug.

> Every so often (I've not quite figured out the exact set of
> circumstances yet)  "git diff-files" shows that every file in my repo
> is modified, when I expect none to be.

Diff-files only looks at the cached sha1 in the index. It will not
re-read the file to update its index entry if its stat information
appears out of date. So what is happening is that another program[1] is
updating the timestamp or other information about each file, but not the
content. Diff-files does not re-read the content to find out there is in
fact no change.

If you are using plumbing like diff-files, you are expected to run "git
update-index --refresh" yourself first. The reasoning is that for
performance reasons, a script that issues many git commands would only
want to pay the price to refresh the index once, at the beginning of the
script.

If you use the "git diff" porcelain, it will automatically refresh the
index for you.

> If I type "git status" (which shows what I expect - no files modified)
> and then "git diff-files" again, git now shows that no files have been
> modified (which is what I expect). It's like "git status" is resetting
> something that "git diff-files" uses.

Exactly. "git status" automatically refreshes the index, and the result
is saved.

> I'm trying to figure out what the problem with "git diff-files" is
> because gitk uses it under the hood, and I think that gitk is
> reporting  erroneous changes (which are also reset by performing a
> "git status" in the repo) in the "patch" files list.

gitk should probably be calling "update-index --refresh" on startup. If
it already is, then it may be that whatever is updating the files is
doing it while gitk is running.

-Peff

[1] Usually stat updates are caused by another program. But we have had
    cases where unusual filesystems yielded inconsistent results from
    stat().
--
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]