So if your "essentially binary" changes are localized to one part of the
file (or
get repetitive inside the file itself in a way that compresses well)
They're not, the data being committed is basically already "compressed" in
a sense, as I understand it, and because the linebreaks are result-length
based and not content-length based (think "gzip --rsyncable") you end up
with diffs that don't work well with git's (frankly black-magic-esque) diff
compression. Though it does still get zlib'd as you say.

The removal of the comments seems to have shrunk the file pretty
dramatically, but if this is going to be updated regularly it may still be
a concern. I wonder if using a different format to store the data may help?
Like storing one node/literal per line (bigger/longer file, but equivalent
results and better diffs?), though I don't fully understand the method
being used in this so I can't speak as to other potential options.

You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 7 | next ›
Discussion Overview
groupgolang-dev @
postedJun 8, '16 at 8:45a
activeJun 12, '16 at 5:53p



site design / logo © 2021 Grokbase