Lazy filesystem (Linux)

I started to be bothered by how Git duplicates my datas... so I intend to make my Git workdirs their own tempfs's, like so: /project/repo (instead of .git) /project/work (instead of ./, and it's a ramdisk mount) Now the issue is, constructing a whole workdir each time is too inefficient as well - but I can ask Git to generate file listings and produce individual files. So is there a way to have a "virtual file system" that only generates the files as-requested? What kind of key / search terms do I need to plausibly find this if it exists? No I'm not adopting GNU hurd, I need this to work on Linux. I did find this: https://github.com/presslabs/gitfs This is a FUSE userspace filesystem backed by a Git repo... but it auto-commits and doesn't run in RAM as far as I can tell.

gitfs sounds like a terrible idea. No commit tagging, and an insane amount of commits assuming you're making one for every write

git already uses delta compression, what are you talking about

>>86158 I'll spell it out: Say I have 1gb of /dev/random output. Then I commit it to git. Now it takes 2gb to store. This is like kicking dead whales down the beach. This is also why git-lfs is like kicking dead whales down the beach. If I instead, remove the default workdir, make a ramdisk, and have git "extract" a copy into that, then it costs 1gb on disk, 1gb in memory and It Just Works. But I have to do at least <repo size> reads each time I've rebooted my PC. This is unnecessary wear on my HDD and is like kicking dead whales down the beach. Now say I have 10x a 1gb file. I do the same thing as before, but instead of checking out every file onto the ramdisk, I only check out a file listing. Then IF I need data from one of the files, I extract it on-demand. This way I only read as much off-disk as needed. This is what I'm looking for.

I'm sure this isn't the answer you're looking for but HDD space is cheap. Using up your limited RAM to save your less limited HDD space doesn't make sense. By the time you figure out a way to hold files in RAM during checkout, you're going to have lost a 512GB SSD's worth of opportunity cost that would have solved your problem. It might be unnecessary reading and writing, but it's virtually insignificant to the lifespan of the drive. Unless you're trying to do this method just to see if you can, just upgrade your drives and keep backups.

>>86164 It surely isn't what I'm looking for even if you're offering to pay for it.

Honestly I still can't tell what the fuarrrk OP means and what is this reading on demand he talks about. When git reconstructs the repo on checkout it will have to read the data and how the kernel is supposed to mind read OP to discern "demand" from git is beyond me. Also storing .git in ram means you loose your entire repo each time you reboot.

Maybe I understand what you mean because a few month ago, I spent some hours trying to make checkouts use reflinking (my work laptop is a Macbook, so APFS). Found out it's not possible because blobs aren't stored as-is, even without compression. So no sharing between them and a worktree.

>>86171 >reading on demand "Partial checkout". >Also storing .git in ram Storing workdir in ram, not .git. >>86172 Yes, to do this requires an on-the-fly translator (a la hurd) or caching a translation at least temporarily (the hack I envision).

make a ramdisk, mount it somewhere, and whenever you want to work on a project just clone the repo there you can use git init --bare to create a project without a workdir

>>86183 Fair, I was trying to skip over this step.

>>86189 I'm sure there must be a way to avoid cloning the entire repository if you are only interested in a few files (to optimize disk usage), and then commit using git add <file> instead of git add . maybe with the "sparse checkout" feature? the setup is very unintuitive but it does more or less what you want

>>86183 >make a ramdisk, mount it somewhere, and whenever you want to work on a project just clone the repo there >you can use git init --bare to create a project without a workdir Yes