Re: Fw: Curiosity
- From
- Martin Fick <mfick@codeaurora.org>
- Date
- Dec 16, 2021, 21:33 UTC
- Message-ID
- <54fe7ba20109f974b61a7e6c24ba8264@codeaurora.org>
- In-Reply-To
- <xndBIO9EtrXaA932eF-0YkvHCAOL1GOKQQlIigssmcwhtZWqGxhc6I_A-lXt7vMK-j1oDrQMHUIuExlpqFS4v88nWci32qx3W5Xi1_hPpUM=@protonmail.com>
On 2021-12-16 14:20, João Victor Bonfim wrote:
Show 11 quoted lines
>> To expand on this, if what you're storing is already compressed, like >> Ogg Vorbis files or PNGs, like are found in that repository, then >> generally they will not delta well. This is also true of things like >> Microsoft Office or OpenOffice documents, because they're essentially >> Zip files. >> >> The delta algorithm looks for similarities between files to compress >> them. If a file is already compressed using something like Deflate, >> used in PNGs and Zip files, then even very similar files will >> generally >> look very different, so deltification will generally be ineffective.
...
Show 10 quoted lines
> Maybe I am thinking too outside the box, but wouldn't it be quite more > effective for git to identify compressed files, specially on edge cases > where the compression doesn't have a good chemistry with delta > compression, > decompress them for repo storage while also storing the compression > algorithm as some metadata tag (like a text string or an ID code > decided > beforehand), and, when creating the work mirrors, return the > compression > to its default state before checkout?
I suspect that for most algorithms and their implementations, this would not result in repeatable "recompressed" results. Thus the checked-out files might be different every time you checked them out. :(
-Martin
-- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation