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

Re: Notes on Using Git with Subprojects

From
A Large Angry SCM <gitzilla@gmail.com>
Date
Sep 26, 2006, 22:33 UTC
Message-ID
<4519AACD.7020508@gmail.com>
In-Reply-To
<20060926213003.GA8177@spearce.org>
Shawn Pearce wrote:
> Daniel Barkalow <barkalow@iabervon.org> wrote:
[...]
Show 19 quoted lines
> I agree entirely.
> 
> I have about 30 "subprojects" tacked into one large Git repository
> for this exact reason.  In at least 5 of these cases they shouldn't
> be sharing a Git repository as by all rights they are different
> projects.
> 
> What I'm doing is sort of like tacking both the Linux kernel and
> glibc into the same Git repository because you might need to change
> and bisect over updates to the system call layer.  Insane, yes.
> Probably shouldn't be done; but right now that interface layer
> between several subprojects is still in flux and it makes it rather
> easy to keep everything in sync.
> 
> Its annoying to perform commits to the "root project" every time the
> subproject changes.  And it brings some complexity when you want to
> talk about merging that root project.  But if its automated as part
> of "git commit" and "git merge" (either directly in those tools or
> by hooks users can install) then its probbaly a non issue.

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.

An operation that _needs_ to change more than one project's versioned state a time should be rare. If you have to do it often, then instead of subprojects you probably have a partitioning of one project. A subproject should be independent of its parent projects. A merge of a parent project should not affect a subproject other than to pick a particular subproject version.

Your example of the kernel and glibc is an example of sibling projects. Each one in independent and (some) versions of each project should work (better or worse) with the other. The root project here shouldn't really do more than specify which version of the kernel and glibc to use.

Previous: Shawn PearceNext: Martin Waitz
Message 8 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.