On Fri, May 20, 2016 at 4:25 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: >> My take is to pretend sparse checkout does not exist at all and then >> go from there ;-) Hehe.. shameless plug, narrow checkout [1] should be its great successor where everything is done right (famous last words). Maybe I can convince Stefan to finish that off then I'll finally bring narrow clone! [1] http://article.gmane.org/gmane.comp.version-control.git/289112 > Using these pathspec attrs are a good example for why we would > want to make it more generic. Imagine a future, where more attributes > can be codified into pathspecs and this is one of the possibilities: > > git clone --sparse=":(exclude,size>5MB,binary) > > which would not checkout files that are large binary files. We could > also extend the protocol (v2 with the capabilities in client speaks first) > to transmit such a requirement to the server. I think you need narrow clone there ;-) It's the first step to have a clone with missing directories. I think then we can extend it further to exclude (large) files. > Why is sparseness considered bad? It does not scale well when the worktree gets bigger. It can be slow (but this is just a technical problem I haven't spent time on fixing). And it does not enable narrow clone (not with lots of hacks, I think I did just that in some early iterations). > If I wanted to just do the submodule only thing, this would be a smaller > series, I would guess. No no no. Do more. Start with narrow checkout. I'll help ;-) -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html