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

Re: RFC: Making submodules "track" branches

From
Johan Herland <johan@herland.net>
Date
Jun 9, 2010, 08:22 UTC
Message-ID
<201006091022.18896.johan@herland.net>
In-Reply-To
<4C0F4185.2000207@web.de>
On Wednesday 09 June 2010, Jens Lehmann wrote:
Show 11 quoted lines
> Am 08.06.2010 23:52, schrieb Johan Herland:
> > The good thing with Ævar's approach is that this is all configurable
> > per branch (indeed, per commit[1]) by editing your .gitmodules file.
> 
> Yep, I think this is the sane way to do that.
> 
> > Interesting. Will the object parsing machinery handle that without
> > hiccups? What if an older Git version tries to checkout/update a
> > submodule with a 0- hash?
> 
> Maybe Ævar's idea of dropping such a submodule from the tree is better.

Agreed. That will of course cause older Git versions to skip the submodule altogether, which is probably the safest failure mode.

Show 6 quoted lines
> > Me too, but I suspect that if you draw the "one big repo" approach to
> > its logical conclusion, there will be some demand for recursive
> > commits.
> 
> You may be right here. But as submodules often have a detached HEAD, this
> might get interesting ;-)

Yes, trying to recursively commit across a submodule with detached HEAD should obviously fail (at least by default). But as long as a local branch is checked out in the submodule (which is not necessarily the same as having the submodule _track_ that branch), a recursive commit should be relatively straightforward.

Show 14 quoted lines
> > [1]: Say your submodule usually tracks a branch, but you're creating
> > some tag in the super-repo, and you want that tag to uniquely identify
> > the submodule. You achieve this by making sure the tagged commit
> > removes the relevant "branch = whatever" line from .gitmodules, and
> > records the appropriate submodule version in the super-repo tree.
> > Then, you can revert the .gitmodules change on the next commit to
> > resume tracking the submodule branch.
> > 
> > Now, whenever you checkout the tag, you will always get the exact same
> > version of the submodule, although the submodule otherwise tracks some
> > branch.
> 
> Won't work anymore when we would use 0{40} or drop it from the tree.
> AFAICS always-tip and referencing a certain commit don't mix well.

AFAICS, it would still work as long as it exists in the tree for that specific commit (but is missing/0{40} in other commits).

We're not mixing "always-tip" and "exact-commit" in the same commit. We use "always-tip" in regular commits, and then temporarily switch to "exact- commit" in the commits where a certain submodule version is required.

...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Previous: Jens LehmannNext: Steven Michalske
Message 11 of 21 in “RFC: Making submodules "track" branches”
  1. Ævar Arnfjörð BjarmasonJun 7, 2010
  2. Johan HerlandJun 8, 2010
  3. Marc BranchaudJun 8, 2010
  4. Ævar Arnfjörð BjarmasonJun 8, 2010
  5. Marc BranchaudJun 8, 2010
  6. Ævar Arnfjörð BjarmasonJun 8, 2010
  7. Marc BranchaudJun 9, 2010
  8. Jens LehmannJun 8, 2010
  9. Johan HerlandJun 8, 2010
  10. Jens LehmannJun 9, 2010
  11. Johan HerlandJun 9, 2010
  12. Steven MichalskeJun 9, 2010
  13. Johan HerlandJun 9, 2010
  14. Junio C HamanoJun 8, 2010
  15. Ævar Arnfjörð BjarmasonJun 8, 2010
  16. Jens LehmannJun 9, 2010
  17. Jens LehmannJun 9, 2010
  18. Marc BranchaudJun 9, 2010
  19. Ævar Arnfjörð BjarmasonJun 9, 2010
  20. nottrobinNov 20, 2012
  21. W. Trevor KingNov 20, 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.