> Nowadays I instead just clone a repo to a ramdisk, purge the .git folder and then rsync it to my hoarded stash of git repos.
You're probably already doing this, but if you do a shallow clone (git clone --depth=1 ..) you'll limit the amount that ends up in .git that you need to purge.
Even with shallow clones, I'm still surprised that it ends up with a .git that's a decent percentage of the total. I just tried it on a repo and ended up with 16% of the total size being .git. I would have guessed that it'd be much smaller than that.
I had also tried that but some repos still get fairly big and all I wanted was the code not the .git since I am not a proper developer. To your point they can still be quite large.
cd /dev/shm/block && git clone -j4 --depth=1 --branch=master https://github.com/firehol/blocklist-ipsets.git
du --max-depth 1 -hc
24M ./ipip_country
4.0M ./ipdeny_country
9.6M ./ip2location_country
6.9M ./geolite2_country
25M ./.git
140M .
140M total
It's not awful but I currently keep up to date copies of about 300 git repos and if I keep all the big ones it can add up to several GB of data I do not need. For now I just clone to a ramdisk and whack the .git directory for several of the big ones before I rsync back to disk. I probably lose some interesting history doing that.
You're probably already doing this, but if you do a shallow clone (git clone --depth=1 ..) you'll limit the amount that ends up in .git that you need to purge.
Even with shallow clones, I'm still surprised that it ends up with a .git that's a decent percentage of the total. I just tried it on a repo and ended up with 16% of the total size being .git. I would have guessed that it'd be much smaller than that.