On Sun, Mar 22, 2020 at 12:45:29PM -0400, Derrick Stolee wrote: > >> I have mixed feelings on this. I do like making things less arcane for > >> users. But are we locking in a behavior for --partial that we might not > >> want to live with forever? I.e., the current thinking for partial clones > >> is to fetch no blobs at all, get all commits and trees, apply sparse > >> filters, and then fault in the blobs we need. But imagine we later grow > >> the ability to easily avoid fetching all of the trees. Would we regret > >> having the simple name "--partial" taken? > > > > I agree with that. Something like "--filter-blobs" for > > "--filter=blob:none" and perhaps "--filter-blobs=<size>" for > > "--filter=blob:limit=<size>" might be worth it though. > > Thanks for the perspective on this. The --filter-blobs[=<size>] should > be less likely to collide with an alternative definition of "partial". Yes, though I wonder if it's really that big an improvement over "--filter=blob:none". > While we are thinking in this space, what if we had a "partial-clone" > builtin? It could be a light wrapper around "git clone" where > > git partial-clone [--limit=<size>] [options] <url> [<dir>] > > would do the same thing as > > git clone --filter=blob:[none|limit=<size>] [options] <url> [<dir>] > > Just spit-balling here. I think that just shifts my concern out to the other command; i.e., would we later want the partial-clone command to behave differently. And introducing a wrapper creates a weird non-orthogonality where it's not necessary. I _do_ think a wrapper could make sense when it's doing substantially different things, or multiple steps that don't belong in the original program (e.g., the way Scalar works). > In the meantime, I'll work to adjust my patches to only be the > documentation of the --filter option. Thanks, that seems like an obvious and easy improvement. -Peff
