Add sparse_checkout option to git source - #9295
Conversation
099d1ce to
90a2722
Compare
d5563c1 to
2b476cf
Compare
ianks
changed the title
sparse_checkout option to git sourcesparse_checkout option to git source
5db6d0b to
27f2eed
Compare
colby-swandale
changed the title
sparse_checkout option to git sourcesparse_checkout option to git source
fc5e8ed to
e416f3e
Compare
| def partial_clone_filter_args | ||
| return [] unless @sparse_checkout && supports_partial_clone? | ||
| ["--filter=blob:none"] | ||
| end |
There was a problem hiding this comment.
Am I correct that this is opinionated in how it combines sparse checkouts and a blobless partial clone? I might have missed it, however you might want to specifically document this, as I understand it does affect the load on the repository manager, and might be of relevance to folks.
Did you consider whether a full tree-less clone (--filter=tree:0) might be even better for the rubygems use case?
There was a problem hiding this comment.
Thanks for the feedback, I was unaware of the --filter=tree:0 option. Seems like a good fit from my glancing of the docs, but are there footguns?
There was a problem hiding this comment.
It's git, there are always footguns right? 😅
I'm not an expert on either of these and usually end up back at https://github.blog/open-source/git/get-up-to-speed-with-partial-clone-and-shallow-clone/ to refresh my memory and think about the consequences for any subsequent operations needed on a given clone.
However, I imagine the footguns might be similar for both of them or even shallow clones.
- issues where people may assume no need for connectivity after initial clone (and related auth issues)
- perhaps some dependency on particular server side support on the repository manager (which people's internal repo managers may not support)
- friendliness to semi-dumb proxies (?)
Probably not familiar enough with Rubygems to know if any of those are a realistic concern.
Cloning the working copy from the remote with a blob filter made every install need the network, and a blobless cache cannot serve the locked revision to the working copy because upload-pack refuses to lazy fetch. Keep the cache complete and apply the sparse cone only to the checkout made from it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The bare cache has no working tree, so the cone only matters for the checkout. Keying the cache by it fetched the same monorepo once per sparse_checkout. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`git sparse-checkout set` only learned --cone in git 2.35. Older versions take it as a pattern and fall back to non-cone matching, which drops the top-level files a cone checkout keeps. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A gem in a monorepo can need a sibling directory besides its own, and git takes several cone directories. Values that are not directory names now raise a Gemfile error instead of a TypeError from computing the install path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Gemspecs outside the cone are never checked out, so a sparse_checkout without glob made users repeat the directory in both options. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
e416f3e to
f621f03
Compare
4 participants
Monorepo cloning can be incredibly slow without
sparse-checkout, so let's add support for a newsparse_checkout: "some/path/to/folder"option