From: Jens Lehmann <Jens.Lehmann@web.de>
To: git@vger.kernel.org
Cc: Jeff King <peff@peff.net>, Marc Branchaud <marcnarc@xiplink.com>,
Junio C Hamano <gitster@pobox.com>
Subject: [PATCH] submodules: recursive fetch also checks new tags for submodule commits
Date: Fri, 13 Apr 2012 18:25:16 +0200 [thread overview]
Message-ID: <4F88536C.2090003@web.de> (raw)
In-Reply-To: <20120413070423.GA16292@sigill.intra.peff.net>
Since 88a21979c (fetch/pull: recurse into submodules when necessary) all
fetched commits are examined if they contain submodule changes (unless
configuration or command line options inhibit that). If a newly recorded
submodule commit is not present in the submodule, a fetch is run inside
it to download that commit.
Checking new refs was done in an else branch where it wasn't executed for
tags. This normally isn't a problem because tags are only fetched with
the branches they live on, then checking the new commits in the fetched
branches for submodule commits will also process all tags. But when a
specific tag is fetched (or the refspec contains refs/tags/) commits only
reachable by tags won't be searched for submodule commits, which is a bug.
Fix that by moving the code outside the if/else construct to handle new
tags just like any other ref. The performance impact of adding tags that
most of the time lie on a branch which is checked anyway for new submodule
commit should be minimal, as since 6859de4 (fetch: avoid quadratic loop
checking for updated submodules) all ref-tips are collected first and then
fed to a single rev-list.
Spotted-by: Jeff King <peff@peff.net>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Am 13.04.2012 09:04, schrieb Jeff King:
> OK, I checked. Yes, we handle this just fine. After my 6859de4, we
> collect the ref tips before and after the fetch and run only a single
> rev-list. So processing the tags will result in just an extra
> interesting commit, which was either:
>
> 1. accessible by another fetched branch, in which case it was going to
> be processed as interesting anyway
>
> 2. not accessible, in which case we have fixed a bug. :)
>
> So I think we should check all incoming refs, including tags.
Thanks for you analysis!
builtin/fetch.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 65f5f9b..cfb43df 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -300,11 +300,11 @@ static int update_local_ref(struct ref *ref,
else {
msg = "storing head";
what = _("[new branch]");
- if ((recurse_submodules != RECURSE_SUBMODULES_OFF) &&
- (recurse_submodules != RECURSE_SUBMODULES_ON))
- check_for_new_submodule_commits(ref->new_sha1);
}
+ if ((recurse_submodules != RECURSE_SUBMODULES_OFF) &&
+ (recurse_submodules != RECURSE_SUBMODULES_ON))
+ check_for_new_submodule_commits(ref->new_sha1);
r = s_update_ref(msg, ref, 0);
strbuf_addf(display, "%c %-*s %-*s -> %s%s",
r ? '!' : '*',
--
1.7.10.131.gd0e498
prev parent reply other threads:[~2012-04-13 16:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-11 14:29 [PATCH] fetch: Only call a new ref a "branch" if it's under refs/heads/ marcnarc
2012-04-12 5:52 ` Jeff King
2012-04-12 20:15 ` Jens Lehmann
2012-04-12 20:36 ` Marc Branchaud
2012-04-12 20:42 ` Jens Lehmann
2012-04-12 21:05 ` Jeff King
2012-04-13 7:04 ` Jeff King
2012-04-13 16:25 ` Jens Lehmann [this message]
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=4F88536C.2090003@web.de \
--to=jens.lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=marcnarc@xiplink.com \
--cc=peff@peff.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).