Closed David-Moody closed 1 year ago
I am willing to implement this. I would go for the second approach and discard the boolean value "zip" in a future version. Because with the string option I could simply set up a switch for the string.
I had a go at implementing this. It's very doable by upgrading github.com/mholt/archiver to v4.
But on further testing, there are marginal gains to be made. Due to the highly compressed nature of a git repo, zstd can only get an additional <1% reduction on very large repos vs zipping. Which itself is only a fractional improvement on the bare folder / tarring / zipping (store only). This doesn't justify the additional complexity introduced by having multiple output types.
Thanks for testing it beforehand
ZIP compression is already an option for local. Though generally not an issue, having lots of large large repos can make ZIP compression not ideal, zstd compression would allow 'state-of-art' compression, saving disk space.
This could be easily added by using archive/tar from the standard library and the pure go zstd implementation: github.com/klauspost/compress.
Would this be of interest / willing to merge?
What are thoughts on implementing / changing Gickup's public interface?
1) Add new bool field "zstd" for the local struct type definition. Process this in the same manner as the "zip" option, triggering the zstd compression. Error if both are set to true. OR 2) Add a "compression" string field. This would then trigger compressing via zip or zstd, and would generalise better for future compression methods. "zip" could be deprecated or left in for backwards compatibility.