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

Re: [RFC PATCH 0/5] Submodule Groups

From
Jens Lehmann <jens.lehmann@web.de>
Date
Dec 1, 2015, 22:06 UTC
Message-ID
<565E19F8.6060101@web.de>
In-Reply-To
<CAGZ79kZGydm=yYkc-Na2QqpGhLB-KEdh7XyxHPYZqZDzpi3F7w@mail.gmail.com>
Am 01.12.2015 um 00:54 schrieb Stefan Beller:
Show 12 quoted lines
> On Wed, Nov 25, 2015 at 11:18 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>>>>
>>>> Hmm, I doubt it makes much sense to add the --group option to "git
>>>> submodule init". I'd rather init all submodules and do the group
>>>> handling only in the "git submodule update" command. That way
>>>> upstream can change grouping later without having the user to
>>>> fiddle with her configuration to make that work.
>>>
>
> Mind to elaborate a bit more here?
> The way I understand you now is to pass not --groups to init,
> but init initializes all submodules. But that is worse IMHO

Hmm, I did not mean to imply that "git init" should initialize all submodules. Me thinks that "git clone --groups" should do that but then only fetch and checkout those submodules the chosen groups select. I expect "git submodule init" to be obsolete when submodule groups (or recursive update) are used, and that's why IMO it doesn't need a --groups option. (If the user wants to change the groups later we might need to teach "git submodule sync" the --groups option though)

Show 6 quoted lines
> (In the naive way of dealing with groups in the first patch series)
> as then we open up two possibilities:
>   * a submodule which happened to be part of the repository
>     when cloning is added to a new group, which a user has
>     configured, on pulling, this is no problem, we just checkout
>     the desired version of the submodule.

That'll only work automatically when we follow my proposal to init all those submodules present on clone, because otherwise it won't be initialized.

>   * a submodule which was not part of the repository at the time
>     of cloning, is added to the superproject with a group the user
>     is subscribed to. This would not be checked out as it is uninitialized
>     on disk.

That's why I propose a mechanism to "auto-init" new submodules on fetching their gitlink in the superproject. Then both your groups proposal and my recursive update could make them appear in the work tree on the next update/checkout. And as fetch is part of clone, I'd expect clone to "auto-init" all submodules referenced in gitlinks too.

Show 21 quoted lines
> So when a change of the set of submodules as defined by groups
> occurs, that is the point in time, when we want to init/fetch/checkout
> these submodules, no?
>
>>>
>>> Well if upstream changes grouping later, you could just run
>>>
>>>       git submodule update --init --groups
>>>
>>> and get what you want?
>>
>>
>> And make life harder than necessary for our users without having
>> a reason for that?
>
> So if upstream changes groups, ideally we want to follow without much
> hassle for the user. So a plain git pull should /just work/. (I am repeating
> myself here I'd guess), we would need to react to that. if we drop the
> --groups call to init, we'd still tell the user to run
>
>       git submodule update
Sure, that's still needed until we have recursive update.
> We do not need --groups any more in a later patch as instead of
> passing in --groups we can detect for `git config submodule.groups`
> to be available or not.
Yes.
> --init should not be needed as when the groups are there we automatically
> init new submodules in the group set?
Right.
Show 10 quoted lines
>> Except for the URL copying submodule settings
>> on init is wrong, as it sets in stone what happened to be in the
>> .gitmodules file when you ran init and doesn't allow upstream to
>> easily change defaults later. We still do that with the update
>> setting for historical reasons, but I avoided making the same
>> mistake with all the options I added later. You can override
>> these settings if you want or need to, but that shouldn't be
>> necessary by default to make life easier for our users.
>>
>
Previous: Stefan BellerNext: Jens Lehmann
Message 23 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.