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

Re: git submodules and commit

From
Nigel Magnay <nigel.magnay@gmail.com>
Date
Jul 16, 2008, 11:02 UTC
Message-ID
<320075ff0807160402s7429291ela288b42d99c1ec53@mail.gmail.com>
In-Reply-To
<487DD1C7.3070701@viscovery.net>
On Wed, Jul 16, 2008 at 11:47 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
Show 12 quoted lines
> Nigel Magnay schrieb:
>> For me, in some really high proportion of cases, I think I want 'git
>> commit' to mean 'commit to any child repositories, any sibling
>> repositories, and any parent repositories (updating the submodule sha1
>> as appropriate). In other words, 'pretend like the whole thing is one
>> big repo'.
>
> And I think that this is the problem: If this way of commiting your
> changes is *required* in the *majority* of cases, then you are IMO outside
> the intended use-case of submodules. You are better served by really
> making this one big repo.
>

Hm - then my contention is that the scope of submodules needs to be expanded (or something needs to be built on top).

One-big-repo doesn't fly - > 75% of the code volume (the 'other' modules) are shared between multiple projects. In SVN these are just svn:externals (which has it's own imperfections).

I think it's a common usecase. You have 'shared' modules and 'project-specific' modules[*]. The 'shared' modules you hope don't change very much, but they are part of the overall project configuration - it's really nice that you can branch so easily in git, then get the module owner to merge those changes into the next release at their leisure. The superproject then represents the correct configuration of submodule trees to make a valid build.

The machinery has everything that's required, it's just the user experience sucks :(

[*] actually there's more subtlety, there's 'shared', 'product' and 'project', so some 'specific' modules are potentially re-shared elsewhere.

Show 7 quoted lines
> IMO, submodules are to be used if you can afford to advance parent project
> and submodules at different paces; i.e. if the parent project can work
> with newer versions of the submodules (and possibly in a degraded mode
> even with outdated versions).
>
> -- Hannes
>
Previous: Johannes SixtNext: Johannes Sixt
Message 3 of 14 in “git submodules and commit”
  1. Nigel MagnayJul 16, 2008
  2. Johannes SixtJul 16, 2008
  3. Nigel MagnayJul 16, 2008
  4. Johannes SixtJul 16, 2008
  5. Petr BaudisJul 16, 2008
  6. Nigel MagnayJul 16, 2008
  7. Johannes SixtJul 16, 2008
  8. Nigel MagnayJul 16, 2008
  9. Petr BaudisJul 16, 2008
  10. Nigel MagnayJul 16, 2008
  11. Avery PennarunJul 16, 2008
  12. Nigel MagnayJul 17, 2008
  13. Avery PennarunJul 17, 2008
  14. Ping YinJul 18, 2008

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.