git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCHv2] builtin/clone: support submodule groups

From
Stefan Beller <sbeller@google.com>
Date
Dec 1, 2015, 18:58 UTC
Message-ID
<CAGZ79kaLKGtfXZpOEY9yR9viwCDfi_cxhwCWNjh5_2qtcdBtzQ@mail.gmail.com>
In-Reply-To
<565D43D1.9030207@drmicha.warpmail.net>

On Mon, Nov 30, 2015 at 10:53 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Show 5 quoted lines
> 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.

Show 5 quoted lines
>
> 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
Previous: Michael J GruberNext: Jens Lehmann
Message 18 of 24 in “Submodule Groups”
  1. 0/5 Submodule GroupsStefan Beller, Nov 25, 2015
  2. 1/5 submodule-config: keep submodule groups aroundStefan Beller, Nov 25, 2015
  3. 2/5 git submodule add can add a submodule with groupsStefan Beller, Nov 25, 2015
  4. 3/5 git submodule init to pass on groupsStefan Beller, Nov 25, 2015
  5. 4/5 submodule--helper: module_list and update-clone have --groups optionStefan Beller, Nov 25, 2015
  6. 5/5 builtin/clone: support submodule groupsStefan Beller, Nov 25, 2015
  7. Jens LehmannNov 25, 2015
  8. Stefan BellerNov 25, 2015
  9. Jens LehmannNov 25, 2015
  10. Stefan BellerNov 25, 2015
  11. Jens LehmannNov 25, 2015
  12. Stefan BellerNov 25, 2015
  13. [PATCHv2] builtin/clone: support submodule groupsStefan Beller, Nov 26, 2015
  14. Stefan BellerNov 26, 2015
  15. Trevor SaundersNov 26, 2015
  16. Stefan BellerNov 30, 2015
  17. Michael J GruberDec 1, 2015
  18. Stefan BellerDec 1, 2015
  19. Jens LehmannNov 25, 2015
  20. Stefan BellerNov 25, 2015
  21. Jens LehmannNov 25, 2015
  22. Stefan BellerNov 30, 2015
  23. Jens LehmannDec 1, 2015
  24. Jens LehmannNov 25, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.