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

Re: Notes on Using Git with Subprojects

From
Martin Waitz <tali@admingilde.org>
Date
Sep 27, 2006, 08:06 UTC
Message-ID
<20060927080652.GA8056@admingilde.org>
In-Reply-To
<4519AACD.7020508@gmail.com>
hoi :)
On Tue, Sep 26, 2006 at 03:33:49PM -0700, A Large Angry SCM wrote:
> So, for each subproject of a parent project, you want to record branch, 
> version (commit ID), and directory location. Not quite as easy to do in 
> a makefile but do-able.
I've been playing with this kind of subprojects a little bit.
My current approach is like this:
 * create a .gitmodules file which lists all the directories
   which contain a submodule.
 * the .git/refs/heads directory of the submodule gets stored in
   .gitmodule/<modulename> inside the parent project
 * both things above should be tracked in the parent project.
   This way you always store the current state of each submodule
   in each commit of the parent project.  And you don't have to
   create a new parent commit for each change.  You can commit
   to the parent project when you think that all your modules are
   in a good state.
 * When checking out a project, all submodules listen in .gitmodules
   get checked out, too.
 * If there is a merge conflict in the module list or its refs/heads,
   this is handled specially, e.g. by triggering a new merge inside
   the submodule.
 * The object directory is shared between the parent and all modules.
   To make fsck-objects happy, the parent gets a refs/module link
   pointing to .gitmodule/ and all submodules get a refs/parent
   link pointing to the refs directory of the parent.

The concept is similiar to the gitlink objects which have been floating around, but it is easier to prototype as no new git object type has to be created. If it works well we can later move the information stored in .gitmodule* into an object type of its own.

By storing the complete refs/heads directory for each submodule instead of only one head, it is possible to track multiple branches of a subproject. I'm don't know yet how this works out in praktice but I think that it can be nice to be able to atomically commit to several branches of one submodule (perhaps one branch per customer, per hardware platform, whatever).

So, what have I done up to now? Not much. I created a little script to set up a submodule as described above: http://git.admingilde.org/?p=tali/git.git;a=blob;f=git-init-module.sh;h=0108873fd3aa8a42035039b19e8555513c075fca;hb=module

Next steps would be to modify clone and checkout to actually be able to work in such a setup. If this works then merging of subprojects has to be done (the most complex part I guess).

-- 
Martin Waitz
Previous: A Large Angry SCMNext: Johannes Schindelin
Message 9 of 39 in “Notes on Using Git with Subprojects”
  1. A Large Angry SCMSep 26, 2006
  2. Johannes SchindelinSep 26, 2006
  3. A Large Angry SCMSep 26, 2006
  4. Johannes SchindelinSep 26, 2006
  5. A Large Angry SCMSep 26, 2006
  6. Daniel BarkalowSep 26, 2006
  7. Shawn PearceSep 26, 2006
  8. A Large Angry SCMSep 26, 2006
  9. Martin WaitzSep 27, 2006
  10. Johannes SchindelinSep 27, 2006
  11. Martin WaitzSep 27, 2006
  12. Johannes SchindelinSep 27, 2006
  13. Sven VerdoolaegeSep 27, 2006
  14. Junio C HamanoSep 27, 2006
  15. Michael S. TsirkinSep 28, 2006
  16. Jeff KingSep 28, 2006
  17. Martin WaitzSep 27, 2006
  18. Johannes SchindelinSep 27, 2006
  19. A Large Angry SCMSep 27, 2006
  20. Johannes SchindelinSep 27, 2006
  21. Shawn PearceSep 27, 2006
  22. Rogan DawesSep 27, 2006
  23. Shawn PearceSep 28, 2006
  24. A Large Angry SCMSep 28, 2006
  25. A Large Angry SCMSep 28, 2006
  26. A Large Angry SCMSep 27, 2006
  27. Jeff KingSep 27, 2006
  28. A Large Angry SCMSep 28, 2006
  29. Jeff KingSep 28, 2006
  30. Shawn PearceSep 28, 2006
  31. Jeff KingSep 28, 2006
  32. Shawn PearceSep 28, 2006
  33. Shawn PearceSep 28, 2006
  34. Johannes SchindelinSep 28, 2006
  35. Martin WaitzSep 28, 2006
  36. A Large Angry SCMSep 28, 2006
  37. Martin WaitzSep 29, 2006
  38. A Large Angry SCMSep 26, 2006
  39. A Large Angry SCMOct 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.