On Mon, Nov 30, 2015 at 10:53 PM, Michael J Gruber
<g...@drmicha.warpmail.net> wrote:
> I think we have to solve more basic issues for sparse checkouts first.
> I'm using them with extra worktrees now and everything seems to be
> working fine. But we need to get the UI right for the simple case (no
> submodules, maybe not even extra worktrees) first: setting up patterns
> before checkout etc. Having submodules in mind doesn't hurt, tough.
Well my thinking comes from the other side: "I want to improve submodule
handling, but do I need to pay any attention to sparse checkout?", as Trevor
pointed out, this may or may not be similar enough from a users perspective,
that we want to have a similar/same UI there.
>
> I still consider sparse checkouts a local "cludge" (not technically
> cludgy) in the sense that it helps you cater to some specific local
> needs; not something whose config you'd want to transport as part of the
> object store.
Right, the submodule groups would be in the same boat. Each user would decide
locally what groups they think is worth having. Unlike the sparse checkout
the repository contains the groups however. As fair as I understand the sparse
checkout you would specify to checkout /foo/* but not checkout /bar/*
Now it is likely that some people will have very similar preferences for their
sparse checkout, so it may make sense to add an abstraction layer in there,
which can be done by groups. These groups could be defined using similar
patterns as in .gitattributes or .gitignore in another .gitgroups file. Maybe
the .gitattributes file could be reused.
The definition of the groups would be in the repository, such that it is kept
maintained and the individual user only needs to specify a few groups they're
interested in.
Currently you can already checkout submodules in a sparse fashion by just
initializing and checking out those submodules you want. But I think this
is not feasible if you have a huge amount of submodules, because you cannot
apply file patterns like you could with a .git{attributes, ignore, groups}
file. Because of the missing pattern, I'd want to add the groups.
>
> Minor implementation detail: Do we have any precedence of comma
> separated values for config values? I'd say we rather use multiple
> entries, don't we?
Ok, I'll fix that.
>
> Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
