Re: Git for games working group

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sep 17, 2018, 15:58 UTC
Message-ID: <20180917155810.GA89942@aiede.svl.corp.google.com>
In-Reply-To: <20180917135846.GG71477@syl>

Taylor Blau wrote:

> On Sun, Sep 16, 2018 at 03:05:48PM -0700, Jonathan Nieder wrote:
> > On Sun, Sep 16, 2018 at 11:17:27AM -0700, John Austin wrote:
> > > Taylor Blau wrote:

Show 18 quoted lines

>>>> Right, though this still subjects the remote copy to all of the
>>>> difficulty of packing large objects (though Christian's work to support
>>>> other object database implementations would go a long way to help this).
>>>
>>> Ah, interesting -- I didn't realize this step was part of the
>>> bottleneck. I presumed git didn't do much more than perhaps gzip'ing
>>> binary files when it packed them up. Or do you mean the growing cost
>>> of storing the objects locally as you work? Perhaps that could be
>>> solved by allowing the client more control (ie. delete the oldest
>>> blobs that exist on the server).
>>
>> John, I believe you are correct.  Taylor, can you elaborate about what
>> packing overhead you are referring to?
>
> Jonathan, you are right. I was also referring about the increased time
> that Git would spend trying to find good packfile chains with larger,
> non-textual objects. I haven't done any hard benchmarking work on this,
> so it may be a moot point.

Ah, thanks.  See git-config(1):

	core.bigFileThreshold
		Files larger than this size are stored deflated,
		without attempting delta compression.

		Default is 512 MiB on all platforms.

If that's failing on your machine then it would be a bug, so we'd definitely want to know.

Jonathan