Re: serious performance issues with images, audio files, and other "non-code" data

From: John <john@puckerupgames.com>
Date: May 24, 2010, 00:21 UTC
Message-ID: <4BF9C678.6010108@puckerupgames.com>
In-Reply-To: <alpine.LFD.2.00.1005181557250.12758@xanadu.home>

Just to follow up, the two solutions which have had a noticeable effect are, first to run daily `gc`s, and, second, to configure a ".gitattributes" file as such:

*.jpg binary -delta *.png binary -delta *.psd binary -delta *.gz binary -delta *.bz2 binary -delta .. and so on.

On my first go-round with ".gitattributes" (earlier in this thread), my patterns were setup incorrectly, as in,

*.{gz,bz2,tgz,psd,png,jpg} binary -delta

Since git does not perform brace expansion, the above patterns never matched. After revising the .gitattributes file, a ~6 minute gc dropped down to just under ~3 minutes.

Is there any reason why someone would NOT want the above ".gitattributes" defined by default?

On 05/18/2010 03:59 PM, Nicolas Pitre wrote:

Show 19 quoted lines

> On Tue, 18 May 2010, Jeff King wrote:
>
>> On Tue, May 18, 2010 at 03:33:58PM -0400, Nicolas Pitre wrote:
>>
>>>> It will have to write the whole 200M packfile out each time, though.
>>>
>>> No.  gc will only create a pack with new loose objects by default.
>>> Only if the number of packs grow too large will it combine them into one
>>> pack.
>>
>> I think that is only "gc --auto".
>
> Argh. You're right.  And "gc --auto" is already ran by many commands
> already.
>
> It is "git repack" that doesn't combine packs by default.
>
>
> Nicolas