Re: problem with BOINC repository and CR/LF

[Junio C Hamano <gitster@pobox.com>]

Toralf Förster <toralf.foerster@gmx.de> writes:

> On 12/18/2012 05:41 PM, Jeff King wrote:
>> I could reproduce it, too, on Linux.
>> 
>> The reason it does not always happen is that git will not re-examine the
>> file content unless the timestamp on the file is older than what's in
>> the index. So it is a race condition for git to see whether the file is
>> stat-dirty.
>
> /me still wonders whether this race condition is a feature or an issue
> in GIT - b/c it means that 2 different people cloning the same
> repository get different results.

The primary point of Peff's demonstration was to show that you told
your repository to lie to Git, I think.  It promised that the
contents in the repository was with certain line endings when they
are not.  At that point Git can do whatever happens when it trusts
its behaviour on that broken promise.

When the timestamp is set one way, Git happened to be extra careful
for other reasons---Git is not in the business of suspecting that
the user lied and double checking by wasting cycles [*1*]---and that
extra check that does not have anything to do with the end-of-line
conversion found that it was lied and noticed differences.

That is neither a feature nor a bug.

[Footnote]

*1* This extra carefulness is to handle the case where *filesystems*
lie to Git.  The user cannot do anything to make the filesystem not
to lie, so we try to be extra careful and examine the contents even
when the stat information (incorrectly) says that the file is not
modified.  Also luckily this happens only to minority of the paths
(i.e. you do "git add" and then replace the file with different
contents of the same length within the same timestamp granularity,
or something like that), so we can afford to.