Re: gitk pays too much attention to file timestamps

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Apr 6, 2010, 23:36 UTC
Message-ID: <20100406233601.GA27533@progeny.tock>
In-Reply-To: <l2hc6c947f61004061557x8085600fif5e973077d9eb4f3@mail.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