Conversation

; git commit -m "Here's all that stuff I've been working on for the last month" error: file write error: No space left on device fatal: unable to write loose object file ; rm -rf ~/.cargo ~/.rustup ; git commit -m "Here's all that stuff I've been working on for the last month"

178

This Tweet was deleted by the Tweet author. Learn more

Teoh Han Hui

@teohhanhui

Sep 9

Replying to @snargleplax and

@thingskatedid

not relevant... they're running out of disk space 🥹

Replying to

@snargleplax and

Can definitely save a ton of space used by Git though: git config --global core.compression 9 && find / -type d -name .git -exec git -C {} gc --aggressive \;

Replying to

and @snargleplax

ooh. thank you!

Replying to

and @snargleplax

Git history gets ridiculously bloated over time. Compacting it all with git gc --aggressive helps a lot. Setting core.compression to 9 gets a little bit more out of the zlib compression. Most size wins come from converting loose objects and smaller packs into unified packs.

Replying to

I'm chronically low on disk space from working on multiple different trees based on Linux, Chromium and the Android Open Source Project. Stuck with this puny 2TB Samsung 980 Pro until they release the 4TB Samsung 990 Pro next year. Have learned lots of ways to save disk space...

Replying to

Can also save tons of space with `cp --reflink` if your filesystem has support (XFS and Btrfs but not ext4). It's essentially fork(...) for files. It uses block-based copy-on-write at the destination. Can copy an identical file over another to deduplicate without sharing writes.

Replying to

I moved to XFS from ext4 for better parallel NVMe performance and started using reflinks a lot. XFS doesn't have transparent compression support yet but I found it hurt build performance too much and most of my space is used by already compressed Git object/pack data anyways.

11:53 PM · Sep 9, 2022Twitter Web App

Retweet

Likes

danny "disco" mcClanahan

Replying to

and

and

developed a git fuse fs which vastly improved checkout time and i was investigating how to make it more performant for large builds when i left twitter. i still think it's feasible to use knowledge of compile output paths to improve perf somehow

danny "disco" mcClanahan

Replying to

actually reducing the underlying disk space used by git wasn't implemented but would be possible by lazily fetching git history and otherwise maintaining a shallow clone. it would be a very large project but it would be fun to work on

Show replies