Re: git diff too slow for a file

From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: Apr 20, 2010, 21:15 UTC
Message-ID: <4BCE1983.4020009@lsrfire.ath.cx>
In-Reply-To: <7vd3xuinbe.fsf@alter.siamese.dyndns.org>

Am 20.04.2010 09:40, schrieb Junio C Hamano:

Show 19 quoted lines

> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> 
>> For Linux, these 161 out of 178107 commits are affected:
>>
>>   90d49b4f  83f3c715  3b5dd52a  e97bd974  4e092d11  96b3c83d  4c96e893
>>   ...
>>   22e2c507  e9edcee0  303b86d9  47b5d69c  2d7edb92  cb624029  f4f051eb
>>
>> I have briefly looked at a few of them.  They were big and not obvious
>> with or without XDF_NEED_MINIMAL, but the flag clearly helped to cut
>> them down a bit.
> 
> Thanks.
> 
> I am getting the same impression after staring some output.
> 
> Probably we should at least try to get rid of the use of MINIMAL
> immediately after 1.7.1 and if nobody finds large discrepancies, aim to
> ship 1.7.2 (and possibly 1.7.1.1) without even --quick/--slow options.

Turning XDF_NEED_MINIMAL off by default looks like the sane thing to do in order to help the fringe cases without hurting the normal ones.

A --slow/--minimal/--try-harder option for git diff could come in handy for longer patches, though. GNU diff has it, too (-d/--minimal).

> I expect that there will also be some differences in the blame output.

I haven't looked at the impact on blame, but additionally patch IDs are going to change (for those patches where XDF_NEED_MINIMAL makes a difference). Are they stored somewhere? Do we need to worry about them?

René