From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sat, 13 Feb 2010 12:12:38 GMT
Subject: Re: 'git add' corrupts repository if the working directory is modified as it runs
Message-ID: <20100213121238.GA2559@progeny.tock>
In-Reply-To: <20100212012314.GC24809@gibbs.hungrycats.org>

Zygo Blaxell wrote:
> On Thu, Feb 11, 2010 at 06:27:41PM -0600, Jonathan Nieder wrote:

>>  - Low-hanging fruit: it should be possible for update-index to check
>>    the stat information to see if the file has changed between when it
>>    first opens it and when it finishes.
>
> I don't think this is a good idea.  stat() is very coarse-grained

You’re probably right.  For many file types, st_size is likely to
change (in this way your script is testing something unusual), but
that is no excuse to behave poorly when it doesn’t.

> What would be a good idea is to make sure that the code that copies a
> file into the index and calculates its hash does both in a single pass
> over the same input data.  That might require replacing a simple mmap()
> of the input file with a read-hash-copy loop.

This leaves me nervous about speed.  Consider the following simple
case: someone the file to be added is already in the object
repository somewhere (maybe the user has tried this code before, or
a file was renamed with 'mv', or a patch applied with 'patch', or an
unmount and remount dirtied the stat information).

With the current code, write_sha1_file() will hash the file, notice
that object is already in .git/objects, and return.  With a
read-hash-copy loop, git would have to store a (compressed or
uncompressed) copy of the file somewhere in the meantime.

But I’d be happy to see code appear that proves me wrong. ;-)  One
simple benchmark to try is running the git test suite.

Cheers,
Jonathan