From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sat, 04 Dec 2010 00:51:32 GMT
Subject: Re: git reset and ctime
Message-ID: <20101204005131.GB15906@burratino>
In-Reply-To: <AANLkTimyYTup+PqJFJ+2g-tVwWXA2bxTT3noonEuKBSu@mail.gmail.com>

Hi Greg,

ghazel@gmail.com wrote:

> I've encountered a strange issue where "git reset --hard" insists on
> "Checking out files ..." when all that is changed is the ctime

There is a performance trade-off.  Refreshing the index requires
reading+hashing the existing file if the stat information changed;
this could be faster or slower than blindly overwriting depending on
the situation.

That said, I have no strong objection to an implicit refresh in "git
reset" (performance-sensitive scripts should be using read-tree
directly anyway).  Have you tried making that change to
builtin/reset.c?  How does it perform in practice?

>              My deploy process (capistrano) maintains a cached copy of
> a git repo, which it fetches, resets, and then hardlinks files from
> when a deploy occurs ( https://github.com/37signals/fast_remote_cache
> ). The hardlinking step is meant to save the time of copying the file.
> but hardlinking changes the ctime of the source files.

Interesting.  Setting "[core] trustctime = false" in the repository
configuration could be a good solution (no performance downside I can
think of).

Hope that helps,
Jonathan