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

Re: organizing multiple repositories with dependencies

From
Ddag@cray.com <dag@cray.com>
Date
Apr 30, 2012, 19:43 UTC
Message-ID
<nngd36pxawy.fsf@transit.us.cray.com>
In-Reply-To
<CABURp0pHcZfUw8p5F=7W3BipGHdc2Q0QQ7WuaPPVWOYdG1S=BQ@mail.gmail.com>
Phil Hord <phil.hord@gmail.com> writes:
Show 20 quoted lines
>> I can't think of a situation where I would need to implement the same
>> or similar features in multiple components where those components are
>> not tightly coupled in some way.
>
> I tend to agree.  However, I have a use case that I suffer on a daily basis.
>
> We have code that runs on multiple platforms (embedded SoCs).  I have
> a superproject that has a common library and some vendor-specific code
> for each supported platform broken out into submodules.
>
>   super-all
>     +-- CommonAPI
>     +-- VendorA
>     +-- VendorB
>     +-- VendorC
>
> The code in the Vendor submodules contains the proprietary
> implementations for specific vendor's systems of the CommonAPI
> library.  When the CommonAPI gets a new feature, it often gets
> implemented in all the vendor submodules as well.
Ah yes, that's a good example.
Show 14 quoted lines
> We could easily do this without submodules, of course.  But this setup
> allows us to define alternative super-projects that we can then share
> with subcontractors and original vendors without exposing proprietary
> third-party code.
>
>   super-B
>     +-- CommonAPI
>     +-- VendorB
>
>   super-C
>     +-- CommonAPI
>     +-- VendorC
>
> We could still handle this with git-subtree.  But we don't.

Yes, I agree that this is a very important use case. This is the case where subprojects exist because of vendor barriers, not necessarily due to software engineering concerns.

                                  -Dave
Previous: Phil HordNext: Jens Lehmann
Message 20 of 34 in “organizing multiple repositories with dependencies”
  1. Namit BhallaApr 16, 2012
  2. Jakub NarebskiApr 16, 2012
  3. dag@cray.comApr 16, 2012
  4. Hilco WijbengaApr 17, 2012
  5. dag@cray.comApr 17, 2012
  6. Seth RobertsonApr 17, 2012
  7. Hilco WijbengaApr 17, 2012
  8. dag@cray.comApr 17, 2012
  9. Hilco WijbengaApr 17, 2012
  10. PJ WeisbergApr 17, 2012
  11. Hilco WijbengaApr 17, 2012
  12. Namit BhallaApr 18, 2012
  13. Jens LehmannApr 18, 2012
  14. dag@cray.comApr 24, 2012
  15. Hilco WijbengaApr 24, 2012
  16. PJ WeisbergApr 24, 2012
  17. Hilco WijbengaApr 24, 2012
  18. dag@cray.comApr 24, 2012
  19. Phil HordApr 30, 2012
  20. dag@cray.comApr 30, 2012
  21. Jens LehmannApr 18, 2012
  22. dag@cray.comApr 24, 2012
  23. Seth RobertsonApr 24, 2012
  24. Jens LehmannApr 24, 2012
  25. Seth RobertsonApr 24, 2012
  26. dag@cray.comApr 24, 2012
  27. username localhostApr 28, 2012
  28. dag@cray.comApr 24, 2012
  29. Seth RobertsonApr 25, 2012
  30. dag@cray.comApr 27, 2012
  31. Eugene SajineApr 24, 2012
  32. Hilco WijbengaApr 24, 2012
  33. dag@cray.comApr 24, 2012
  34. dag@cray.comApr 24, 2012

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.