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

Re: [RFC/PATCH] add update to branch support for "floating submodules"

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 10, 2011, 06:30 UTC
Message-ID
<7vborhaqgw.fsf@alter.siamese.dyndns.org>
In-Reply-To
<loom.20111210T062013-538@post.gmane.org>
Leif Gruenwoldt <leifer@gmail.com> writes:
Show 7 quoted lines
> Our use case is as follows. We have several repositories for our common code 
> (commonA.git, commonB.git, etc) and a few different products that leverage these 
> common repos (productA.git, productB.git, etc). When one of the products is in 
> heavy development we often need to do a lot of work in the common repos. Having 
> to increment the sha1 of the submodules to track the latest tip would be overly 
> arduous. (Obviously when development of the product stabilizes we would want to 
> change to anchoring to a specific sha1 in the common repos).

Nobody forces you to update the commit in the submodule bound to the superproject tree every time you update areas that are unrelated to or independent from that frequently updated submodule.

During the period the submodule is so often updated that you feel "having to increment ... would be overly arduous", it does not matter which exact commit in that submodule is used in the tree for your other modules and the superproject. Otherwise you _would_ want to say something like "for this entire tree state from the top-level superproject to correctly work, we absolutely need to have this commit, not any commit that is older and is known to be broken, from this submodule", and cannot afford to use floating.

Which means by definition anybody who wants floating can instead let such an often updated submodule stay somewhat stale by not running "submodule update" for it unnecessarily. In a well-modularized set of projects, the interface to the busy submodule may be stable and I can imagine that kind of arrangement would well be not just possible but practical, and probably yours may be such a project.

So that use case does not sound like a good rationale to require addition of floating submodules.

Previous: Jonathan NiederNext: Leif Gruenwoldt
Message 6 of 27 in “add update to branch support for "floating submodules"”
  1. add update to branch support for "floating submodules"Heiko Voigt, Nov 9, 2011
  2. Junio C HamanoNov 9, 2011
  3. Heiko VoigtNov 29, 2011
  4. Leif GruenwoldtDec 10, 2011
  5. Jonathan NiederDec 10, 2011
  6. Junio C HamanoDec 10, 2011
  7. Leif GruenwoldtDec 10, 2011
  8. Andreas T.AuerDec 12, 2011
  9. Leif GruenwoldtDec 12, 2011
  10. Andreas T.AuerDec 12, 2011
  11. Leif GruenwoldtDec 12, 2011
  12. Jens LehmannDec 12, 2011
  13. Phil HordDec 12, 2011
  14. Marc BranchaudDec 13, 2011
  15. Jens LehmannDec 13, 2011
  16. Marc BranchaudDec 13, 2011
  17. Junio C HamanoDec 12, 2011
  18. Phil HordDec 13, 2011
  19. Jens LehmannDec 13, 2011
  20. Phil HordJan 30, 2012
  21. Jens LehmannJan 31, 2012
  22. Phil HordJan 31, 2012
  23. Jens LehmannFeb 1, 2012
  24. Phil HordFeb 6, 2012
  25. Jens LehmannFeb 6, 2012
  26. Brandon CaseyDec 13, 2011
  27. Gioele BarabucciDec 10, 2011

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.