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

[PATCH v2 0/3] Teach fetch and pull to recursively fetch submodules too

From
Jens Lehmann <jens.lehmann@web.de>
Date
Oct 5, 2010, 20:43 UTC
Message-ID
<4CAB8DDF.8080004@web.de>
In-Reply-To
<28BC3A45-D3CF-4A8C-A818-B92A9827C8FB@sb.org>
So here is the next iteration of the recursive fetching for submodules.
Changes to the first patchset and its fixes:
* Squashed all fixes into the first patch
* Added the new config setting 'fetch.recursive' to set the default
  for all submodules
IMO this patchset should replace the one currently in pu.
Still unresolved issues:
1) Performance
   Kevin reported the fetch time went up from 1.5s to 20s for him
   because of the recursion. Kevin, could you please test the branch
   "parallel-submodule-fetch" from my github repository:
      http://github.com/jlehmann/git-submod-enhancements.git
   It has these three patches based on next plus a preliminary
   commit fetching submodules in parallel (but note that a limit
   of 128 submodules is hardcoded and the output might be mixed
   between the fetch threads, I'll fix that when you confirm the
   performance benefit I expect).
   (It took me some time to get that working, the DNS server in my
   DSL router seems to silently drop IPv6 requests. This lead to a
   15 second timeout in getaddrinfo() when forking fetch commands
   in quick succession, turning the intended speedup into a
   massive slowdown. If you happen to run into the same issue,
   please try the "broken-dns-server-hack" branch which contains a
   workaround for that issue).
2) The proper default
   Kevin argues that submodule fetching should only happen when new
   commits for the submodule have been fetched (which is kind of
   similar to what "git submodule update" does now), while I argue
   that submodules should always be fetched by default, no matter
   if new commits from submodules are committed inside the
   superproject or not.
   Ok, lets look at the basic ways you can run the fetch command and
   look at possible defaults:
   a) "git fetch --all"
      The user wanted to fetch new commits from all remotes. I think
      git should also fetch all submodules then, no matter if new
      commits from them are fetched in the superproject, as the user
      explicitly said he wants everything. Objections?
   b) "git fetch [<repository>]"
      The user wants to fetch from the default [or a single repo]. I
      think all submodules should be fetched too, Kevin thinks this
      should happen only when it is necessary (at least for his 'H'
      repository). While I think fetching all submodules too is
      consistent with the fact that you get all branches in the
      superproject too, whether you need them or not, we can't seem
      to agree on this one (also see my proposal below).
   c) "git fetch [<repository>] <refspec>"
      If the user wants to fetch only commits from a certain refspec,
      I think that it is sane to let git fetch only those submodules
      where new commits were fetched in the superproject as he was
      explicitly asking only for a subset of available commits.
   Assuming we agree on a) and - the still to be implemented - c), It
   looks like we need a new config setting for 'fetch.recursive' and
   'submodule.<name>.fetch', say 'changed'? This would allow Kevin to
   set 'submodule.H.fetch' to 'changed' in the .gitmodules describing
   it. Then "git fetch" would only then recurse further when new
   commits from 'H' have been used in the commits fetched in its
   superproject. Would that be an acceptable solution?
Jens Lehmann (3):
  fetch/pull: Recursively fetch populated submodules
  Submodules: Add the new "fetch" config option for fetch and pull
  Add the 'fetch.recursive' config setting
 Documentation/config.txt        |   10 ++
 Documentation/fetch-options.txt |   15 +++
 Documentation/gitmodules.txt    |    8 ++
 builtin/fetch.c                 |   58 ++++++++---
 git-pull.sh                     |   10 ++-
 submodule.c                     |   91 +++++++++++++++++-
 submodule.h                     |    3 +
 t/t5526-fetch-submodules.sh     |  209 +++++++++++++++++++++++++++++++++++++++
 t/t7403-submodule-sync.sh       |    2 +-
 9 files changed, 388 insertions(+), 18 deletions(-)
 create mode 100755 t/t5526-fetch-submodules.sh
-- 
1.7.3.1.108.gb6303
Previous: Kevin BallardNext: Jens Lehmann
Message 27 of 55 in “Teach fetch and pull to recursively fetch submodules too”
  1. 0/2 Teach fetch and pull to recursively fetch submodules tooJens Lehmann, Aug 29, 2010
  2. 1/2 fetch/pull: Recursively fetch populated submodulesJens Lehmann, Aug 29, 2010
  3. 2/2 Submodules: Add the new "fetch" config optionJens Lehmann, Aug 29, 2010
  4. Junio C HamanoAug 30, 2010
  5. 2/2 Submodules: Add the new "fetch" config option for fetch and pullJens Lehmann, Aug 30, 2010
  6. Ævar Arnfjörð BjarmasonAug 29, 2010
  7. Jens LehmannAug 29, 2010
  8. Junio C HamanoAug 30, 2010
  9. Jens LehmannAug 30, 2010
  10. Kevin BallardSep 15, 2010
  11. Kevin BallardSep 15, 2010
  12. fetch: Get submodule paths from index and not from .gitmodulesJens Lehmann, Sep 16, 2010
  13. Kevin BallardSep 16, 2010
  14. Jens LehmannSep 17, 2010
  15. Johannes SixtSep 17, 2010
  16. Jens LehmannSep 17, 2010
  17. Johannes SixtSep 17, 2010
  18. Jens LehmannSep 17, 2010
  19. Johannes SixtSep 17, 2010
  20. Kevin BallardSep 18, 2010
  21. 0/2 fix problems with recursive submodule fetchingJens Lehmann, Sep 18, 2010
  22. 1/2 fetch: Fix a bug swallowing the output of recursive submodule fetchingJens Lehmann, Sep 18, 2010
  23. 2/2 fetch: Get submodule paths from index and not from .gitmodulesJens Lehmann, Sep 18, 2010
  24. Kevin BallardSep 19, 2010
  25. Jens LehmannSep 19, 2010
  26. Kevin BallardSep 20, 2010
  27. 0/3 Teach fetch and pull to recursively fetch submodules tooJens Lehmann, Oct 5, 2010
  28. 1/3 fetch/pull: Recursively fetch populated submodulesJens Lehmann, Oct 5, 2010
  29. 2/3 Submodules: Add the new "fetch" config option for fetch and pullJens Lehmann, Oct 5, 2010
  30. Jon SeymourOct 7, 2010
  31. Jens LehmannOct 9, 2010
  32. Jonathan NiederOct 9, 2010
  33. Jens LehmannOct 9, 2010
  34. 3/3 Add the 'fetch.recursive' config settingJens Lehmann, Oct 5, 2010
  35. Junio C HamanoOct 5, 2010
  36. Kevin BallardOct 6, 2010
  37. Jonathan NiederOct 6, 2010
  38. Jens LehmannOct 9, 2010
  39. Jonathan NiederOct 9, 2010
  40. Jens LehmannOct 9, 2010
  41. Jonathan NiederOct 21, 2010
  42. Jens LehmannOct 21, 2010
  43. Jens LehmannOct 9, 2010
  44. Marc BranchaudOct 13, 2010
  45. Jens LehmannOct 13, 2010
  46. Kevin BallardOct 13, 2010
  47. Jens LehmannOct 13, 2010
  48. Kevin BallardOct 13, 2010
  49. Chris PackhamOct 14, 2010
  50. Jens LehmannOct 14, 2010
  51. Chris PackhamOct 14, 2010
  52. Marc BranchaudOct 13, 2010
  53. Kevin BallardOct 13, 2010
  54. Jens LehmannSep 15, 2010
  55. Kevin BallardSep 15, 2010

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.