[Openmcl-devel] ccl 1.11 release and GitHub

Alexey Veretennikov txm.fourier at gmail.com
Tue Feb 14 11:35:40 PST 2017


This is not correct. Git stores:
- objects (in .git/objects) - these are zlib-compressed files.
- pack files (in .git/objects/pack) - they contain both objects and
compressed deltas (diffs).

Git uses sophisticated heuristics to determine if the files should be
stored as diffs. You can invoke this heuristics running git gc however.

When you do the clone from repository, you only receive pack files.

For details see here: https://git-scm.com/book/en/v2/Git-Internals-Packfiles

Ron Garret <ron at flownet.com> writes:

> On Feb 14, 2017, at 12:09 AM, Ralf Mattes <rm at seid-online.de> wrote:
>> On Mon, Feb 13, 2017 at 08:24:15PM -0600, mikel evins wrote:
>>> The main problem with storing binaries in git repositories is that git's diff
>>> algorithm is designed for diffing text files. It doesn't get particularly
>>> good results in the general case on binary objects. The practical result is
>>> that, in effect, any time you change a binary object, no matter how small the
>>> change, git will store a whole new copy of the entire binary object.
>> ??? Are aou shure this is correct? AFAIK git _always_ stores files and
>> not diffs. That's one of the biggest differences with older/traditional
>> version control systems. That's the reason checkouts/branch swithxing is
>> so blazingly fast. 
>>> That means that repos containing binaries that change often will tend to grow
>>> in size very much faster than repos that contain only text.
>> I think this is wrong. Change one whitespace in a text file and a new
>> object is created (named by it's md5 sum. Commits pretty much only
>> ppoint to a collection of md5 sums).
> You are correct, Ralf.  Git never stores diffs.  The reason binaries cause repo
> bloat is that they tend to be much bigger than source files.
> rg
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel


More information about the Openmcl-devel mailing list