Git clone –depth 2 is vastly better than –depth 1 if you want to Git push later
13 comments
·February 12, 2025jbreckmckye
Why can't git push, when it encounters a `.git/shallow`, just ask the git server to fill in the remaining history by verifying the parent hashes the client can send?
necovek
I like the fact that none of this was tested, even if described with such authority :)
Anyone try it out yet?
(Not that I don't trust it, but I usually fetch the full history locally anyway)
Timwi
This seems like a bug to me. Even if the previous commit is “mangled” as they call it, there's no reason why you can't diff against it and only send the diff.
haunter
Wait is this a bug actually?
edflsafoiewq
Do blobless clones suffer from this?
jakub_g
From my experience, I heavily don't recommend blobless/treeless clones for local dev. They should only be used in CI for throwaway build & forget scenario.
When you have blobless/treeless clone on local, it will fetch missing blobs on-demand when doing random `git` operations, in the least expected moments, and it does this very inefficiently, one-by-one, which is super slow. (I also didn't find a way to go back from blobless/treeless clone to a normal clone, i.e. to force-fetch all missing blobs efficiently).
It's especially tricky when those `git` operations happen in background e.g. from a GUI (IDE extension etc.) and you don't have any feedback what is happening.
Some further reading:
- https://github.blog/open-source/git/get-up-to-speed-with-par...
- https://github.blog/open-source/git/git-clone-a-data-driven-...
nopurpose
blobless still better than shallow because at least commit history is preserved.
jakub_g
It might be fine for small repos, but for massive repos, blobless/treeless clones become unmanageable because many git operations become very slow. I added some further links.
From my side, when you have non-trivial sized repo, on local machine one should either use either a shallow, or a full clone (or, if possible, a sparse checkout, but this requires repo to be compatible).
I'm wondering what the "because when we read it in, we mangle it" part really means... does this mean that there's no way to reference the commit (signaling that it's just a reference and has no actual data) without actually reading the contents of it?
-- Update: just realized why it wouldn't make sense: `git push` would send only the delta from the previous commit and the previous commit is... non-existent (we only know it's ID), so we'd be back in square 1 (sending everything).