git reset and ctime

>              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.

> 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).

>>>              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).
>
> This is a very useful suggestion. I do not see a case where ctime
> would be valuable to me. Is it really valuable to other people? What
> is the trade-off?

> 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.

> >              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).

>> Interesting.  Setting "[core] trustctime = false" in the repository
>> configuration could be a good solution (no performance downside I can
>> think of).
>
> It is worth noting that many file-based backup systems which do "online"
> backups (such as in use where I work) restore the atime by default at
> the expense of the ctime (logic being that the atime may have had value
> and the ctime changes either way--which may or may not be true) on unix
> style filesystems.

> Drew Northup wrote:
> > On Fri, 2010-12-03 at 18:51 -0600, Jonathan Nieder wrote:
> 
> >> Interesting.  Setting "[core] trustctime = false" in the repository
> >> configuration could be a good solution (no performance downside I can
> >> think of).
> >
> > It is worth noting that many file-based backup systems which do "online"
> > backups (such as in use where I work) restore the atime by default at
> > the expense of the ctime (logic being that the atime may have had value
> > and the ctime changes either way--which may or may not be true) on unix
> > style filesystems.
> 
> So have you tried putting "[core] trustctime = false" in /etc/gitconfig?
> This is exactly what the setting is for, after all.