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

Re: [RFC] Submodules in GIT

From
Martin Waitz <tali@admingilde.org>
Date
Dec 1, 2006, 12:28 UTC
Message-ID
<20061201122854.GR18810@admingilde.org>
In-Reply-To
<200612011212.35656.andyparkins@gmail.com>
hoi :)
On Fri, Dec 01, 2006 at 12:12:34PM +0000, Andy Parkins wrote:
Show 10 quoted lines
> On Friday 2006 December 01 11:10, Sven Verdoolaege wrote:
> 
> > You were proposing to create an extra object containing some random value
> > that is disconnected from the repo.
> 
> Right, I think I've finally understood what Martin (and you) are
> proposing.  You want every commit in the submodule to be propagated up
> to the supermodule as well.  Okay.
> 
> I don't think it's right, but at least I understand.

Please note that the submodule commits are not part of the supermodule commit chain, they are part of the supermodule _tree_.

> It seems wrong because it's making commits in the supermodule that aren't 
> commits to do with that project.

Of course they are part of your project, just like all the tree and blob objects, too.

> In my libxcb example; why should every project use libxcb in have to
> store the entire history of libxcb?

Because you want to be able to use the submodule as a repository of its own, too. Be able to look at its history if you want to. Be able to merge with new versions of the submodule. This is what distiguishes a submodule from a pure file-based import of another project.

> When examining the supermodule history, I won't care about how libxcb
> got to the state its in, and it's just noise in the supermodule
> history.  What if I use 10 submodules, the supermodule history won't
> show you anything useful - it's just unrelated submodule commits.
Again: the submodules are part of your supermodule _tree_, not it's
commit chain.  So you won't see the submodule commits when you invoke
git-log in the supermodule.
> It gets worse, this is why I was asking for more detail: this commit
> that you're storing in the supermodule.  It's the same commit as is in
> the submodule?
It is _the_ commit from the submodule, yes.
> What would the parent commit of that commit be?  It has to be the same
> in both, because the commit-hash forces it to be.

It is the commit of the submodule, so its parents point to the submodule history.

Show 6 quoted lines
> > > Is that commit in the submodule or the supermodule?
> >
> > It's in BOTH.  That's why it's a *sub*module.
> 
> If it's in BOTH then the supermodule is a normal git repository.  You aren't 
> tracking the submodule, you're just including it en masse.

The submodule is part of the entire project, so yes, it is included. And the supermodule tracks submodule development by storing references to the submodule history that was used at that time.

Lets try to paint a little diagram:

belongint to: /--------- supermodule -------\ /---- submodule -------\

commit -> tree +-> blob
  |            +-> tree -> ...
  |            +-----------------> commit -> tree -> ...
  v                                  |
commit -> tree +-> ...               v
  |            +-----------------> commit -> ...
  |                                  |
  |                                  v
  |                                commit -> ...
  v                                  |
commit -> tree +-> ...               v
               +-----------------> commit

Both have their independent history, but they are linked as some submodule versions are part of the supermodule tree.

-- 
Martin Waitz
Previous: Andy ParkinsNext: Andy Parkins
Message 68 of 82 in “Re: [RFC] Submodules in GIT”
  1. Jakub NarebskiNov 20, 2006
  2. Martin WaitzNov 20, 2006
  3. Junio C HamanoNov 20, 2006
  4. Jakub NarebskiNov 20, 2006
  5. Martin WaitzNov 20, 2006
  6. Sam VilainNov 21, 2006
  7. Linus TorvaldsNov 20, 2006
  8. J. Bruce FieldsNov 20, 2006
  9. Martin WaitzNov 20, 2006
  10. J. Bruce FieldsNov 21, 2006
  11. Martin WaitzNov 21, 2006
  12. Martin WaitzNov 20, 2006
  13. Junio C HamanoNov 21, 2006
  14. Jakub NarebskiNov 21, 2006
  15. Martin WaitzNov 21, 2006
  16. Jakub NarebskiNov 21, 2006
  17. Martin WaitzNov 21, 2006
  18. Martin WaitzNov 21, 2006
  19. Junio C HamanoNov 21, 2006
  20. Martin WaitzNov 21, 2006
  21. Yann DirsonNov 21, 2006
  22. Linus TorvaldsNov 21, 2006
  23. Linus TorvaldsNov 21, 2006
  24. Yann DirsonNov 21, 2006
  25. Shawn PearceNov 22, 2006
  26. Yann DirsonNov 23, 2006
  27. Shawn PearceNov 25, 2006
  28. Yann DirsonNov 25, 2006
  29. Linus TorvaldsNov 25, 2006
  30. Steven GrimmNov 25, 2006
  31. Linus TorvaldsNov 25, 2006
  32. Yann DirsonNov 25, 2006
  33. Sven VerdoolaegeNov 26, 2006
  34. Yann DirsonNov 26, 2006
  35. Linus TorvaldsNov 26, 2006
  36. Daniel BarkalowNov 26, 2006
  37. Andreas EricssonNov 28, 2006
  38. Daniel BarkalowNov 28, 2006
  39. Sven VerdoolaegeNov 28, 2006
  40. Daniel BarkalowNov 28, 2006
  41. Sven VerdoolaegeNov 28, 2006
  42. Daniel BarkalowNov 28, 2006
  43. Shawn PearceNov 28, 2006
  44. Daniel BarkalowNov 28, 2006
  45. Linus TorvaldsNov 28, 2006
  46. Stephan FederNov 30, 2006
  47. Andy ParkinsNov 30, 2006
  48. Sven VerdoolaegeNov 30, 2006
  49. Andy ParkinsNov 30, 2006
  50. Andreas EricssonNov 30, 2006
  51. Andy ParkinsNov 30, 2006
  52. Sven VerdoolaegeNov 30, 2006
  53. Andy ParkinsDec 1, 2006
  54. Jakub NarebskiDec 1, 2006
  55. Sven VerdoolaegeDec 1, 2006
  56. Andy ParkinsDec 1, 2006
  57. Martin WaitzNov 30, 2006
  58. sfNov 30, 2006
  59. sfNov 30, 2006
  60. Andy ParkinsDec 1, 2006
  61. Martin WaitzDec 1, 2006
  62. Andy ParkinsDec 1, 2006
  63. Sven VerdoolaegeDec 1, 2006
  64. Andy ParkinsDec 1, 2006
  65. Sven VerdoolaegeDec 1, 2006
  66. sfDec 1, 2006
  67. Andy ParkinsDec 1, 2006
  68. Martin WaitzDec 1, 2006
  69. Andy ParkinsDec 1, 2006
  70. Martin WaitzDec 1, 2006
  71. Martin WaitzDec 1, 2006
  72. Andy ParkinsDec 1, 2006
  73. Martin WaitzDec 1, 2006
  74. Andy ParkinsDec 1, 2006
  75. Martin WaitzDec 1, 2006
  76. Martin WaitzDec 1, 2006
  77. Andy ParkinsDec 1, 2006
  78. Martin WaitzDec 1, 2006
  79. Jakub NarebskiDec 2, 2006
  80. Andy ParkinsDec 1, 2006
  81. Andreas EricssonDec 1, 2006
  82. Andy ParkinsDec 1, 2006

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.