> "fetched naively" here means doing a full `git clone` on every need for `git checkout`, which of course nobody should do,
replyIt can be cheaper to do a full clone than a shallow one, because with the shallow one, you can't re-use packfiles. GitHub has fairly regularly asked people to stop doing shallow clones because it's harder on their servers than full ones.
Makes sense. I wasn't suggesting that one should do a shallow clone though. If your company repo is 100 GB, it seems sensible to keep it cached locally on each machine once (100 GB isn't large for current NVMe disks), and `git fetch` the updates the normal way. Then checkouts don't fetch anything large.
replyIt sounds like it would be simple, but there are a lot of logistical issues with making git happy with this in practice. Repacking things for repo maintenance, for example, but there are many other problems.
replyAh, yes, you can do stuff like that too, for sure.
replyAt some point you still end up running into the issues the article talks about, all of these approaches only get you so far.