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

git submodules

From
Pierre Habouzit <madcoder@debian.org>
Date
Jul 28, 2008, 16:20 UTC
Message-ID
<20080728162003.GA4584@artemis.madism.org>

While trying to sum up some things I'd like submodules to do, and things like that, I came to ask myself why the heck we were doing things the way we currently do wrt submodules.

This question is related to the `.git` directories of submodules. I wonder why we didn't chose to use a new reference namespace (refs/submodules/$path/$remote/$branch).

This would have the net benefit that most of the plumbing tasks would be easier if they have to deal with submodules, because they aren't in this uncomfortable situation where they have to recurse into another git directory to know what to do.

It also has the absolutely nice property to share objects, so that projects that replaced a subdirectory with a submodule don't see their checkouts grow too large.

We probably still want submodules to act like plain independant git repositories, but one can still *fake* that this way: submodules have only a .git/config file (also probably an index and a couple of things like that, but that's almost a different issue for what I'm considering now) that has the setting:

    [core]
        submodule = true
This could make all the builtins look for the real $GIT_DIR up, which in
turn gives the submodule "name". Then, for this submodule, every
reference, remote name, ... would be virtualized using the
"remote/$submodule_name" prefix. IOW, in a submodule "some/sub/module"
the branch "origin/my/topic/branch" is under:
  refs/submodules/some/sub/module/origin/my/topic/branch
  <-- submod. --><-- submod.  --><-- --><--  branch  -->
     namespace 	     path/name   remote
Note that this doesn't mean that we must rip out .gitmodules, because
it's needed to help splitting the previous reference name properly, and
for bootstrapping purposes.

Having that, one can probably extend most of the porcelains in _very_ straightforward ways. For example, a local topic branch `topic` would be the union of the supermodule `topic` branch, and all the `refs/submodules/$names/topic` ones.

Most importantly, it would help implementing that tries to make your submodules stay _on branch_. One irritating problem with submodules, is that when someone else commited, and that you git submodule update, you're on a detached head. Absolutely horrible. If you see your current branch (assume it's master), then when you do that, you would update your `refs/submodules/$name/master` references instead and keep the submodule HEADs `on branch`. Of course we can _probably_ hack something together along those lines with the current setup, but it would be _so_ much more convenient this way...

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
Next: Pierre Habouzit
Message 1 of 29 in “git submodules”
  1. Pierre HabouzitJul 28, 2008
  2. Pierre HabouzitJul 28, 2008
  3. Nigel MagnayJul 28, 2008
  4. Pierre HabouzitJul 28, 2008
  5. Pierre HabouzitJul 28, 2008
  6. Avery PennarunJul 28, 2008
  7. Pierre HabouzitJul 28, 2008
  8. Jakub NarebskiJul 28, 2008
  9. Junio C HamanoJul 28, 2008
  10. Pierre HabouzitAug 17, 2008
  11. Avery PennarunAug 17, 2008
  12. Junio C HamanoAug 17, 2008
  13. Pierre HabouzitAug 18, 2008
  14. Avery PennarunJul 28, 2008
  15. Pierre HabouzitJul 28, 2008
  16. Benjamin CollinsJul 29, 2008
  17. Shawn O. PearceJul 29, 2008
  18. Nigel MagnayJul 29, 2008
  19. Pierre HabouzitJul 29, 2008
  20. Pierre HabouzitJul 29, 2008
  21. Pierre HabouzitJul 29, 2008
  22. Petr BaudisJul 29, 2008
  23. Johannes SchindelinJul 29, 2008
  24. Pierre HabouzitJul 29, 2008
  25. Johannes SchindelinJul 29, 2008
  26. Pierre HabouzitJul 29, 2008
  27. Nigel MagnayJul 29, 2008
  28. Pierre HabouzitJul 29, 2008
  29. Junio C HamanoJul 29, 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.