Re: Bug with disabling compression and 'binary' files.

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 16, 2016, 01:42 UTC
Message-ID: <xmqqk2c4ryj8.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CA+i4re65SsxcaLcpGyMDnJygQFmAq4X_x_uxrkqB0yqQkEYPUQ@mail.gmail.com>

Douglas Cox <ziflin@gmail.com> writes:

Show 12 quoted lines

> I narrowed this down to the '-text' attribute that is set when
> specifying 'binary'.  For some reason this flag is cancelling out the
> core.compression = 0 setting and I think this is a bug?
>
> Unfortunately core.compression = 0 is also global. Ideally it would be
> great if there was a separate 'compression' attribute that could be
> specified in .gitattributes per wildcard similar to how -delta can be
> used. This way we would still be able to get compression for
> text/source files, while still getting the speed of skipping
> compression for binary files that do not compress well.
>
> Has there been any discussion on having an attribute similar to this?

Nope.

I do not offhand think of a way for '-text' attribute (or any attribute for what matter) to interfere with compression level, but while reading the various parts of the system that futz with the compression level configuration, I noticed one thing. When we do an initial "bulk-checkin" optimization that sends all objects to a single packfile upon "git add", the packfile creation uses its own compression level that is not affected by any configuration or command line option. This may or may not be related to the symptom you are observing (if it is, then you would see a packfile created in objects/pack/, not in loose objects in object/??/ directories).