Re: problem with modification time of packfiles

From: Andreas Amann <a.amann@ucc.ie>
Date: Oct 19, 2015, 19:59 UTC
Message-ID: <87a8re4oks.fsf@msstf091.ucc.ie>
In-Reply-To: <20151019025727.GA23404@vauxhall.crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Show 26 quoted lines

> On Sun, Oct 18, 2015 at 10:37:55PM +0100, Andreas Amann wrote:
>> git (2.6.1) sometimes updates the modification time of a packfile, even if it
>> has not changed at all.
>> 
>> On my system this triggers quite expensive an d unnecessary backup
>> operations, which I would prefer to avoid.  Is there a simple way to
>> keep the mtime of packfiles fixed, once they are created?
>> 
>> Apparently the undesired mtime update is done in
>> sha1_file.c:freshen_file() which is called (indirectly) by
>> write_sha1_file().  However I did not understand, why this is done.
>> 
>> Any clarification and pointers, how mtime can be kept constant would be
>> appreciated.
>
> This is required to avoid deleting items that might still be needed.
> The commit message for the commit that introduced that function is as
> follows:
>
>   write_sha1_file: freshen existing objects
>   
>   When we try to write a loose object file, we first check
>   whether that object already exists. If so, we skip the
>   write as an optimization. However, this can interfere with
>   prune's strategy of using mtimes to mark files in progress.
>

Thank you for your answer. However, this reasoning only applies to loose objects and not packfiles.

My understanding is that "git prune" will not prune any pack files (except those starting with tmp_). Only "git repack" should do that. Repack seems to be however mtime agnostic and therefore it does not seem to be necessary to freshen packfiles.

It therefore seems that git freshens packfiles unnecessarily, which can lead to expensive and unnecessary backup operations.

Given this, would a trivial patch to remove the freshening of packfiles be acceptable?

Alternatively, maybe it would be preferrable to use ctime instead of mtime to mark recently used packfiles and loose objects? This might be more natural, as mtime is usually associated with a "modification" of the file itself, which does not happen here. ctime on the other hand indicates attribute changes. (Instead of utime() in this case chmod() could be used to update ctime.)