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

Re: [RFC] Submodules in GIT

From
Ssf <sf@b-i-t.de>
Date
Nov 30, 2006, 16:05 UTC
Message-ID
<456F0153.5000107@b-i-t.de>
In-Reply-To
<200611301449.55171.andyparkins@gmail.com>
Andy Parkins wrote:
Show 9 quoted lines
> On Thursday 2006 November 30 14:00, Stephan Feder wrote:
> 
>> Again I do not see the problem. Probably I have a much simpler picture
>> of submodules: They are just commits in the supermodule's tree.
>> Everything else follows naturally from how git currently behaves.
> 
> How are these commits any different from just having one big repository?  If 
> some of the development of the submodule is contained in the supermodule then 
> it's not a submodule anymore.

Right now you only have commits of the top directory aka the super project. Every subdirectory is just that: a directory (which git stores as trees).

Now, if you have a subdirectory that git stores as a commit, not a tree, you have a subproject. It is a directory with history, and because the commit is part of your superprject, you have access to this history.

> Why bother with all the effort to make a separation between submodule and 
> supermodule and then store the submodule commits in the supermodule.  That's 
> not supermodule/submodule git - that's just normal git.

No, it is not. Currently, there is no way to store a commit within the contents of another commit. You can only store trees and blobs.

Show 15 quoted lines
> Surely the whole point of having submodule's is so that you can take the 
> submodule away.  Let me give you an example.  Let's say I have a project that 
> uses the libxcb library (some random project out in the world that uses git).  
> I've arranged it something like this:
> 
> myproject (git root)
>  |----- src
>  |----- doc
>  `----- libxcb (git root)
> 
> This works fine; with one problem.  When I make a commit in myproject, there 
> is no link into the particular snapshot of the libxcb that I used at that 
> moment.  If libxcb moves on, and makes incompatible changes, then when I 
> checkout an old version of myproject, it won't compile any more because I'll 
> need to find out which commit of libxcb I used at the time.
OK.
> Submodules will solve this problem.  In the future I'll be able to check out 
> any commit of myproject and it will automatically checkout the right commit 
> from the libxcb repository.
OK, I am still with you so far.
Show 5 quoted lines
> Now let's say I'm working away and find a bug in 
> libxcb; I fix it, commit it.  That change had better be stored in the libxcb 
> repository, and had better make no reference to the myproject repository.  If 
> it doesn't, I'm going to have to pollute the libxcb upstream repository with 
> myproject if I want to share those fixes.
Here comes the part where we did not meet before.

Of course you do not make any reference from your subproject to your superproject. You do exactly what you do in git today when you work with different branches:

Step 1: You fix a bug in myproject's subdirectory libxcb.

Step 2: You commit to myproject. myproject now contains a new commit object in path libxcb. (How to do that is up to the UI but at the repository level the outcome should be obvious). This commit is local to your repository.

Step 3: You propose your changes to the libxcb upstream (it might not be a repository you have write access to). I use the following made up syntax (see man git-rev-parse):

A suffix : followed by a path, _followed by a suffix //::_ names the _revision_ at the given path in the tree-ish object named by the part before the colon.

Step 3a: Generate a patch
git diff libxcb//^..libxcb//
Step 3b: Push your changes
git push <libxcb-repository> HEAD:libxcb//:<branch in libxcb-repository>
Step 3c: Let your changes be pulled

"Hello, please pull <myproject-repository> HEAD:libxcb//:<branch in libxcb-repository>"

Step 4: Pull upstream version (hopefully with your changes, otherwise you have to merge)

git pull <libxcb-repository> <branch in libxcb-repository>::HEAD:libxcb//
See, it works.
 From what I understand you want to do the commit and push steps in one 
go. How do you want to record local (to your superproject) changes to 
the subproject?
Regards
Previous: Martin WaitzNext: sf
Message 58 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.