submodules: recursive fetch also checks new tags for submodule commits
authorJens Lehmann <Jens.Lehmann@web.de>
Fri, 13 Apr 2012 16:25:16 +0000 (18:25 +0200)
committerJunio C Hamano <gitster@pobox.com>
Sat, 14 Apr 2012 23:26:57 +0000 (16:26 -0700)
commita6801adc5249c847a596a0d36ffce2a649bc4ade
tree2e343933ebaad7805390e0e25771fce7467ab7ac
parent6eab5f2f14806cf6a7b665d96766a59c13a41f4b
submodules: recursive fetch also checks new tags for submodule commits

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>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/fetch.c