Conversation
099d1ce to
90a2722
Compare
d5563c1 to
2b476cf
Compare
sparse_checkout option to git sourcesparse_checkout option to git source
5db6d0b to
27f2eed
Compare
sparse_checkout option to git sourcesparse_checkout option to git source
27f2eed to
fc5e8ed
Compare
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.
Monorepo cloning can be incredibly slow without
sparse-checkout, so let's add support for a newsparse_checkout: "some/path/to/folder"option