Stefan Beller <sbeller@xxxxxxxxxx> writes: > (B) requires some thought though. Here is my vision: > > 1) Allow pathspecs for sparse checkout. > > I wonder if we just add support for that in .git/info-sparse-checkout > or if we add a new file that is for pathspecs only, or we have a config > option whether sparse-checkout follows pathspecs or gitignore patterns > > 2) Teach `git clone` a new option `--sparse-checkout <pathspec>` > When that option is set the pathspec is written into the new file from > (1) and core.sparsecheckout is set to true > > 3) Advertise to do a `git clone --sparse-checkout > :(attr:default_submodules)` > > Going this way we would help making submodules not different but integrate more > into other concepts of Git. As a downside this would require touching > sparse checkout which may be more time consuming than just adding a > `git clone --init-submodules-by-label` which stores the labels and only upddates > those submodules. > > Or are there other ideas how to go from here? My take is to pretend sparse checkout does not exist at all and then go from there ;-) It is a poorly designed and implemented "concept" that we do not want to spread around. You were going to add defaultGroup and teach 'clone' (and other commands) about it, and have clone find submodules in that Group, right? Isn't the pathspec magic just another way to introduce how you express the "defaultGroup", i.e. not with the "label" thing in .gitmodules, but with pathspec elements with attribute magic? -- 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