From: Jens Lehmann <Jens.Lehmann@web.de>
To: Kevin Ballard <kevin@sb.org>
Cc: Junio C Hamano <gitster@pobox.com>,
Git Mailing List <git@vger.kernel.org>
Subject: [PATCH v2 0/3] Teach fetch and pull to recursively fetch submodules too
Date: Tue, 05 Oct 2010 22:43:11 +0200 [thread overview]
Message-ID: <4CAB8DDF.8080004@web.de> (raw)
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
next prev parent reply other threads:[~2010-10-05 20:43 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-29 15:49 [RFC PATCH 0/2] Teach fetch and pull to recursively fetch submodules too Jens Lehmann
2010-08-29 15:50 ` [PATCH 1/2] fetch/pull: Recursively fetch populated submodules Jens Lehmann
2010-08-29 15:51 ` [PATCH 2/2] Submodules: Add the new "fetch" config option Jens Lehmann
2010-08-30 7:34 ` Junio C Hamano
2010-08-30 17:37 ` [PATCH 2/2 v2] Submodules: Add the new "fetch" config option for fetch and pull Jens Lehmann
2010-08-29 17:29 ` [RFC PATCH 0/2] Teach fetch and pull to recursively fetch submodules too Ævar Arnfjörð Bjarmason
2010-08-29 22:34 ` Jens Lehmann
2010-08-30 5:58 ` Junio C Hamano
2010-08-30 17:41 ` Jens Lehmann
2010-09-15 0:18 ` Kevin Ballard
2010-09-15 2:40 ` Kevin Ballard
2010-09-16 13:55 ` [PATCH] fetch: Get submodule paths from index and not from .gitmodules Jens Lehmann
2010-09-16 19:29 ` Kevin Ballard
2010-09-17 11:31 ` Jens Lehmann
2010-09-17 12:06 ` Johannes Sixt
2010-09-17 12:22 ` Jens Lehmann
2010-09-17 12:32 ` Johannes Sixt
2010-09-17 14:01 ` Jens Lehmann
2010-09-17 14:14 ` Johannes Sixt
2010-09-18 0:29 ` Kevin Ballard
2010-09-18 22:32 ` [PATCH 0/2] fix problems with recursive submodule fetching Jens Lehmann
2010-09-18 22:33 ` [PATCH 1/2] fetch: Fix a bug swallowing the output of " Jens Lehmann
2010-09-18 22:35 ` [PATCH 2/2] fetch: Get submodule paths from index and not from .gitmodules Jens Lehmann
2010-09-19 3:54 ` [PATCH 0/2] fix problems with recursive submodule fetching Kevin Ballard
2010-09-19 16:40 ` Jens Lehmann
2010-09-20 6:40 ` Kevin Ballard
2010-10-05 20:43 ` Jens Lehmann [this message]
2010-10-05 20:43 ` [PATCH 1/3] fetch/pull: Recursively fetch populated submodules Jens Lehmann
2010-10-05 20:44 ` [PATCH 2/3] Submodules: Add the new "fetch" config option for fetch and pull Jens Lehmann
2010-10-07 13:33 ` Jon Seymour
2010-10-09 19:22 ` Jens Lehmann
2010-10-09 19:54 ` Jonathan Nieder
2010-10-09 20:12 ` Jens Lehmann
2010-10-05 20:45 ` [PATCH 3/3] Add the 'fetch.recursive' config setting Jens Lehmann
2010-10-05 21:06 ` [PATCH v2 0/3] Teach fetch and pull to recursively fetch submodules too Junio C Hamano
2010-10-06 22:52 ` Kevin Ballard
2010-10-06 23:22 ` Jonathan Nieder
2010-10-09 19:28 ` Jens Lehmann
2010-10-09 20:02 ` Jonathan Nieder
2010-10-09 20:37 ` Jens Lehmann
2010-10-21 18:29 ` Jonathan Nieder
2010-10-21 21:15 ` Jens Lehmann
2010-10-09 19:17 ` Jens Lehmann
2010-10-13 14:48 ` Marc Branchaud
2010-10-13 19:32 ` Jens Lehmann
2010-10-13 19:34 ` Kevin Ballard
2010-10-13 20:06 ` Jens Lehmann
2010-10-13 20:11 ` Kevin Ballard
2010-10-14 1:01 ` Chris Packham
2010-10-14 18:14 ` Jens Lehmann
2010-10-14 18:31 ` Chris Packham
2010-10-13 21:27 ` Marc Branchaud
2010-10-13 21:31 ` Kevin Ballard
2010-09-15 11:32 ` [RFC PATCH 0/2] " Jens Lehmann
2010-09-15 23:12 ` Kevin Ballard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CAB8DDF.8080004@web.de \
--to=jens.lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kevin@sb.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.