3 ms·

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. Whe

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-partial-clone-and-shallow-clone/#user-content-what-do-the-numbers-say https://github.blog/open-source/git/get-up-to-speed-with-par... - https://github.blog/open-source/git/git-clone-a-data-driven-study-on-cloning-behaviors/ https://github.blog/open-source/git/git-clone-a-data-driven-...

nopurpose 2y ago
blobless still better than shallow because at least commit history is preserved.
- jakub_g 2y ago
  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).
  - nopurpose 2y ago
    you are comparing what is possible but can be slow with blobless with what is impossible with shallow, which is unfair.
    - cluckindan 2y ago
      Given that remote git repos are fundamentally incremental in nature, the limit of impracticality is infinite and eventually must equal impossibility. There is a Moore’s law analogue buried there somewhere in how fast repos grow in relation to network and computing resources (an increase in which of course also makes repos grow faster)

nopurpose 2y ago

blobless still better than shallow because at least commit history is preserved.

jakub_g 2y ago
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).
- nopurpose 2y ago
  you are comparing what is possible but can be slow with blobless with what is impossible with shallow, which is unfair.
  - cluckindan 2y ago
    Given that remote git repos are fundamentally incremental in nature, the limit of impracticality is infinite and eventually must equal impossibility. There is a Moore’s law analogue buried there somewhere in how fast repos grow in relation to network and computing resources (an increase in which of course also makes repos grow faster)