From: Junio C Hamano <hidden> Date: 2016-06-15 22:51:31
Jens Lehmann [off-list ref] writes:
I agree that 33f072f introduced a regression. One could argue if it was
a good idea to let "git submodule init" not do the clone itself but defer
it to "git submodule update" by setting the url in .git/config, but that's
the way things are done now (and maybe there was a very good reason to do
it that way I'm not aware of, because I didn't follow the list that closely
back then).
Actually, shouldn't the fix be more like this patch, which is directly on
top of 33f072f? I think this is more in line with what the end user wants
to tell the system with "submodule init", namely "I am interested in this
submodule".
-- >8 --
Subject: submodule sync: do not auto-vivify uninteresting submodule
Earlier 33f072f (submodule sync: Update "submodule.<name>.url" for empty
directories, 2010-10-08) attempted to fix a bug where "git submodule sync"
command does not update the URL if the current superproject does not have
a checkout of the submodule.
However, it did so by unconditionally registering submodule.$name.url to
every submodule in the project, even the ones that the user has never
showed interest in at all by running 'git submodule init' command. This
caused subsequent 'git submodule update' to start cloning/updating submodules
that are not interesting to the user at all.
Update the code so that the URL is updated from the .gitmodules file only
for submodules that already have submodule.$name.url entries, i.e. the
ones the user has showed interested in having a checkout.
Signed-off-by: Junio C Hamano <redacted>
---
git-submodule.sh | 23 +++++++++++++----------
t/t7403-submodule-sync.sh | 13 +++++++++++--
2 files changed, 24 insertions(+), 12 deletions(-)
@@ -66,7 +67,7 @@ test_expect_success '"git submodule sync" should update submodule URLs' ')'-test_expect_success'"git submodule sync" should update submodule URLs if not yet cloned''+test_expect_success'"git submodule sync" should update known submodule URLs''(cdempty-clone&&gitpull&&gitsubmodulesync&&
@@ -74,4 +75,12 @@ test_expect_success '"git submodule sync" should update submodule URLs if not ye)'+test_expect_success'"git submodule sync" should not vivify uninteresting submodule''+(cdtop-only-clone&&+gitpull&&+gitsubmodulesync&&+test-z"$(gitconfigsubmodule.submodule.url)"+)+'+ test_done
From: Andreas Köhler <hidden> Date: 2016-06-15 22:51:31
Am 24.06.2011 00:28, schrieb Junio C Hamano:
---8<---
Subject: submodule sync: do not auto-vivify uninteresting submodule
Earlier 33f072f (submodule sync: Update "submodule.<name>.url" for empty
directories, 2010-10-08) attempted to fix a bug where "git submodule sync"
command does not update the URL if the current superproject does not have
a checkout of the submodule.
However, it did so by unconditionally registering submodule.$name.url to
every submodule in the project, even the ones that the user has never
showed interest in at all by running 'git submodule init' command. This
caused subsequent 'git submodule update' to start cloning/updating submodules
that are not interesting to the user at all.
Update the code so that the URL is updated from the .gitmodules file only
for submodules that already have submodule.$name.url entries, i.e. the
ones the user has showed interested in having a checkout.
---8<---
I think that describes the situation pretty well and the patch looks
good. I will not be able to test it before next week though, do not wait
for me.
There are two minor issues for me left.
(1) The man page of submodule sync talks about "all submodules" and not
"registered submodules". I treated it as "subsequent init" and
personally do not restrict the list of submodules, simply because my
build would not work without them.
(2) It is confusing to have registered submodules in .git/config without
a matching gitlink. Say, you switch between branch a1 with a submodule s
with url u1, to a branch without s, you git clean -xdff (url u1 is still
in .git/config, right?), and then to a branch a2 with s pointing to url
u2. This bugged me.
Ciao,
-- andi5
There are two minor issues for me left.
(1) The man page of submodule sync talks about "all submodules" and not
"registered submodules". I treated it as "subsequent init" and
personally do not restrict the list of submodules, simply because my
build would not work without them.
While investigating this I stumbled across that too, will post a patch.
(2) It is confusing to have registered submodules in .git/config without
a matching gitlink. Say, you switch between branch a1 with a submodule s
with url u1, to a branch without s, you git clean -xdff (url u1 is still
in .git/config, right?), and then to a branch a2 with s pointing to url
u2. This bugged me.
I think that is ok, because that way git remembers that the user cares
about submodule s even when he switches to a branch where s doesn't
exist. And the documentation is pretty clear that you'll have to use
"git submodule sync" to update the url itself from u1 to u2 when needed.
From: Junio C Hamano <redacted>
Earlier 33f072f (submodule sync: Update "submodule.<name>.url" for empty
directories, 2010-10-08) attempted to fix a bug where "git submodule sync"
command does not update the URL if the current superproject does not have
a checkout of the submodule.
However, it did so by unconditionally registering submodule.$name.url to
every submodule in the project, even the ones that the user has never
showed interest in at all by running 'git submodule init' command. This
caused subsequent 'git submodule update' to start cloning/updating submodules
that are not interesting to the user at all.
Update the code so that the URL is updated from the .gitmodules file only
for submodules that already have submodule.$name.url entries, i.e. the
ones the user has showed interested in having a checkout.
Acked-by: Jens Lehmann <redacted>
Signed-off-by: Junio C Hamano <redacted>
---
Am 24.06.2011 00:28, schrieb Junio C Hamano:
Actually, shouldn't the fix be more like this patch, which is directly on
top of 33f072f? I think this is more in line with what the end user wants
to tell the system with "submodule init", namely "I am interested in this
submodule".
Yes, I am convinced your patch is the doing Right Thing. I squashed in a
change to the git submodule sync documentation (explicitly stating that a
sync only affects submodules which have an url entry in .git/config) and
two more lines in the test you added to make sure that explicitly giving
a submodule on the command line uses the same logic.
What do you think?
(I'll send another patch shortly addressing the failing tests when
jl/submodule-add-relurl-wo-upstream is merged into this one)
Documentation/git-submodule.txt | 4 +++-
git-submodule.sh | 23 +++++++++++++----------
t/t7403-submodule-sync.sh | 15 +++++++++++++--
3 files changed, 29 insertions(+), 13 deletions(-)
@@ -167,7 +167,9 @@ commit for each submodule. sync:: Synchronizes submodules' remote URL configuration setting- to the value specified in .gitmodules. This is useful when+ to the value specified in .gitmodules. It will only affect those+ submodules which already have an url entry in .git/config (that is the+ case when they are initialized or freshly added). This is useful when submodule URLs change upstream and you need to update your local repositories accordingly. +
@@ -66,7 +67,7 @@ test_expect_success '"git submodule sync" should update submodule URLs' ')'-test_expect_success'"git submodule sync" should update submodule URLs if not yet cloned''+test_expect_success'"git submodule sync" should update known submodule URLs''(cdempty-clone&&gitpull&&gitsubmodulesync&&
@@ -74,4 +75,14 @@ test_expect_success '"git submodule sync" should update submodule URLs if not ye)'+test_expect_success'"git submodule sync" should not vivify uninteresting submodule''+(cdtop-only-clone&&+gitpull&&+gitsubmodulesync&&+test-z"$(gitconfigsubmodule.submodule.url)"&&+gitsubmodulesyncsubmodule&&+test-z"$(gitconfigsubmodule.submodule.url)"+)+'+ test_done