Re: gitk pays too much attention to file timestamps

[Jonathan Nieder <jrnieder@gmail.com>]

Hi!

Alexander Gladysh wrote:

> When I "touch" a file, gitk lists it in "local uncommitted changes,
> not checked in to index" (without a difference, just a name). I
> believe that it should not.

First, an explanation:

In general, git keeps some stat(2) information to tell whether an
entry in the index is "dirty".  This way, low-level commands can
compare that to the metadata in the file to avoid a costly
comparison of actual objects to the content of files on disk.

Before starting work, the high-level commands like ‘git commit’ will
generally update this stat(2) information in one pass before doing
anything else.  This turns any "dirty" entries without actually
different content in the index into clean entries, so the user doesn’t
have to worry about anything except content for these commands.  You
can request this update at any time yourself with the following
command:

  git update-index --refresh -q

Unlike ‘git checkout HEAD -- .’ this does not touch the files in
your work tree, and unlike ‘git reset HEAD’, it does not affect the
content registered in the index for your files.

Okay, on to your topic:

gitk is something of a passive observer of the index, which is
actually something I like about it.  This keeps it relatively fast
and can be useful when trying to understand other commands.

I am not sure how other people use gitk, though.  Maybe this would
be worth changing.  For a reference point, another command in a
very similar situation is ‘git diff’: people who want the speedup
from avoiding refreshing the index with that command use

	[diff]
		autoRefreshIndex = false

in their configuration file, so the rest of us don’t have to suffer
from the confusing behavior.

As some kind of evil compromise, it might be worth teaching gitk
to check the same configuration and run update-index --refresh in
getcommits{} if and only if it is unset or set to true.

Thoughts?
Jonathan