How big is a Git commit?

> The du options are: s to summarize and b to display bytes.

Small nitpick: Use long options and your code samples become self explanatory!

I played with making a git alternative that was streamlined according to workflow. I haven't completely abandoned it, but my core idea was that you can use ast path to compress the data further.

Like you said git is really efficient, and even though I went in with some criticism because of the work(mess) that is chromium and the deep hacking I did there to fix stuff between versions without forcing a complete rebuild

I came to the conclusion that as a compression alternative, my approach wasn't worth it. Git did a better job!

Anyway here's the attempt: https://github.com/pankon/gat

Maybe worth adding is that those 250 files are stored as a single blob object since their content and consequently their hash is identical. So in this example, a lot of storage is actually reused.

Git was designed with assumptions about local file storage which make it challenge when storing data in a distributed file system. We built our distributed filesystem, HopsFS, to store data in S3. To support high performance git in FUSE, our writes hit remote NVMe disk(s) and asynchronously sync to S3 (you can replicate on NVMes or just do failure recovery). Previously, we used remote NVMe disks as a write-through cache, but that doesn't work with git, S3 latency is too high.

In newer versions of Git you check this by using the new command `git repo structure`[1]

[1] https://git-scm.com/docs/git-repo#Documentation/git-repo.txt...

Does git support better compression algorithms than deflate, like zstd or brotli?

It can get even smaller when loose objects get packed into packfiles because of delta compression: a whole bunch of identical files can be stored in minimal overhead over storing one copy.

du -sh

Human readable, no explanation required.

Did you do —apparent-size?

[flagged]

[dead]