diff mbox series

[v2] submodule--helper: fix initialization of warn_if_uninitialized

Message ID pull.1258.v2.git.git.1650890741430.gitgitgadget@gmail.com (mailing list archive)
State New, archived
Headers show
Series [v2] submodule--helper: fix initialization of warn_if_uninitialized | expand

Commit Message

Orgad Shaneh April 25, 2022, 12:45 p.m. UTC
From: Orgad Shaneh <orgads@gmail.com>

The .warn_if_uninitialized member was introduced by 48308681
(git submodule update: have a dedicated helper for cloning,
2016-02-29) to submodule_update_clone struct and initialized to
false.  When c9911c93 (submodule--helper: teach update_data more
options, 2022-03-15) moved it to update_data struct, it started
to initialize it to true but this change was not explained in
its log message.

The member is set to true only when pathspec was given, and is
used when a submodule that matched the pathspec is found
uninitialized to give diagnostic message.  "submodule update"
without pathspec is supposed to iterate over all submodules
(i.e. without pathspec limitation) and update only the
initialized submodules, and finding uninitialized submodules
during the iteration is a totally expected and normal thing that
should not be warned.

Signed-off-by: Orgad Shaneh <orgads@gmail.com>
---
    submodule--helper: fix initialization of warn_if_uninitialized
    
    The .warn_if_uninitialized member was introduced by 48308681 (git
    submodule update: have a dedicated helper for cloning, 2016-02-29) to
    submodule_update_clone struct and initialized to false. When c9911c93
    (submodule--helper: teach update_data more options, 2022-03-15) moved it
    to update_data struct, it started to initialize it to true but this
    change was not explained in its log message.
    
    The member is set to true only when pathspec was given, and is used when
    a submodule that matched the pathspec is found uninitialized to give
    diagnostic message. "submodule update" without pathspec is supposed to
    iterate over all submodules (i.e. without pathspec limitation) and
    update only the initialized submodules, and finding uninitialized
    submodules during the iteration is a totally expected and normal thing
    that should not be warned.
    
    Signed-off-by: Orgad Shaneh orgads@gmail.com

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1258%2Forgads%2Fsub-no-warn-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1258/orgads/sub-no-warn-v2
Pull-Request: https://github.com/git/git/pull/1258

Range-diff vs v1:

 1:  089a52a50b4 ! 1:  1e34c9cad18 submodule--helper: fix initialization of warn_if_uninitialized
     @@ Metadata
       ## Commit message ##
          submodule--helper: fix initialization of warn_if_uninitialized
      
     -    This field is supposed to be off by default, and it is only enabled when
     -    running `git submodule update <path>`, and path is not initialized.
     +    The .warn_if_uninitialized member was introduced by 48308681
     +    (git submodule update: have a dedicated helper for cloning,
     +    2016-02-29) to submodule_update_clone struct and initialized to
     +    false.  When c9911c93 (submodule--helper: teach update_data more
     +    options, 2022-03-15) moved it to update_data struct, it started
     +    to initialize it to true but this change was not explained in
     +    its log message.
      
     -    Commit c9911c9358 changed it to enabled by default. This affects for
     -    example git checkout, which displays the following warning for each
     -    uninitialized submodule:
     -
     -    Submodule path 'sub' not initialized
     -    Maybe you want to use 'update --init'?
     -
     -    Amends c9911c9358e611390e2444f718c73900d17d3d60.
     +    The member is set to true only when pathspec was given, and is
     +    used when a submodule that matched the pathspec is found
     +    uninitialized to give diagnostic message.  "submodule update"
     +    without pathspec is supposed to iterate over all submodules
     +    (i.e. without pathspec limitation) and update only the
     +    initialized submodules, and finding uninitialized submodules
     +    during the iteration is a totally expected and normal thing that
     +    should not be warned.
      
          Signed-off-by: Orgad Shaneh <orgads@gmail.com>
      
     @@ builtin/submodule--helper.c: struct update_data {
       	.single_branch = -1, \
       	.max_jobs = 1, \
      -	.warn_if_uninitialized = 1, \
     -+	.warn_if_uninitialized = 0, \
       }
       
       static void next_submodule_warn_missing(struct submodule_update_clone *suc,


 builtin/submodule--helper.c | 1 -
 1 file changed, 1 deletion(-)


base-commit: 6cd33dceed60949e2dbc32e3f0f5e67c4c882e1e

Comments

Junio C Hamano April 25, 2022, 6:25 p.m. UTC | #1
"Orgad Shaneh via GitGitGadget" <gitgitgadget@gmail.com> writes:

> The member is set to true only when pathspec was given, and is
> used when a submodule that matched the pathspec is found
> uninitialized to give diagnostic message.  "submodule update"
> without pathspec is supposed to iterate over all submodules
> (i.e. without pathspec limitation) and update only the
> initialized submodules, and finding uninitialized submodules
> during the iteration is a totally expected and normal thing that
> should not be warned.
> ...
>  builtin/submodule--helper.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> index 2c87ef9364f..1a8e5d06214 100644
> --- a/builtin/submodule--helper.c
> +++ b/builtin/submodule--helper.c
> @@ -2026,7 +2026,6 @@ struct update_data {
>  	.references = STRING_LIST_INIT_DUP, \
>  	.single_branch = -1, \
>  	.max_jobs = 1, \
> -	.warn_if_uninitialized = 1, \
>  }

Is this a fix we can protect from future breakge by adding a test or
tweaking an existing test?  It is kind of surprising if we did not
have any test that runs "git submodule update" in a superproject
with initialized and uninitialized submodule(s) and make sure only
the initialized ones are updated.  It may be the matter of examining
the warning output that is currently ignored in such a test, if
there is one.

Thanks.
Junio C Hamano April 25, 2022, 8:56 p.m. UTC | #2
Junio C Hamano <gitster@pobox.com> writes:

> Is this a fix we can protect from future breakge by adding a test or
> tweaking an existing test?  It is kind of surprising if we did not
> have any test that runs "git submodule update" in a superproject
> with initialized and uninitialized submodule(s) and make sure only
> the initialized ones are updated.  It may be the matter of examining
> the warning output that is currently ignored in such a test, if
> there is one.

Here is a quick-and-dirty one I came up with.  The superproject
"super" has a handful of submodules ("submodule" and "rebasing"
being two of them), so the new tests clone the superproject and
initializes only one submodule.  Then we see how "submodule update"
with pathspec works with these two submodules (one initialied and
the other not).  In another test, we see how "submodule update"
without pathspec works.

I'll queue this on top of your fix for now tentatively.  If nobody
finds flaws in them, I'll just squash it in soonish before merging
the whole thing for the maintenance track.

Thanks.

 t/t7406-submodule-update.sh | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git c/t/t7406-submodule-update.sh w/t/t7406-submodule-update.sh
index 000e055811..43f779d751 100755
--- c/t/t7406-submodule-update.sh
+++ w/t/t7406-submodule-update.sh
@@ -670,6 +670,39 @@ test_expect_success 'submodule update --init skips submodule with update=none' '
 	)
 '
 
+test_expect_success 'submodule update with pathspec warns against uninitialized ones' '
+	test_when_finished "rm -fr selective" &&
+	git clone super selective &&
+	(
+		cd selective &&
+		git submodule init submodule &&
+
+		git submodule update submodule 2>err &&
+		! grep "Submodule path .* not initialized" err &&
+
+		git submodule update rebasing 2>err &&
+		grep "Submodule path .rebasing. not initialized" err &&
+
+		test_path_exists submodule/.git &&
+		test_path_is_missing rebasing/.git
+	)
+
+'
+
+test_expect_success 'submodule update without pathspec updates only initialized ones' '
+	test_when_finished "rm -fr selective" &&
+	git clone super selective &&
+	(
+		cd selective &&
+		git submodule init submodule &&
+		git submodule update 2>err &&
+		test_path_exists submodule/.git &&
+		test_path_is_missing rebasing/.git &&
+		! grep "Submodule path .* not initialized" err
+	)
+
+'
+
 test_expect_success 'submodule update continues after checkout error' '
 	(cd super &&
 	 git reset --hard HEAD &&
Glen Choo April 27, 2022, 10:19 p.m. UTC | #3
"Orgad Shaneh via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Orgad Shaneh <orgads@gmail.com>
>
> The .warn_if_uninitialized member was introduced by 48308681
> (git submodule update: have a dedicated helper for cloning,
> 2016-02-29) to submodule_update_clone struct and initialized to
> false.  When c9911c93 (submodule--helper: teach update_data more
> options, 2022-03-15) moved it to update_data struct, it started
> to initialize it to true but this change was not explained in
> its log message.
>
> The member is set to true only when pathspec was given, and is
> used when a submodule that matched the pathspec is found
> uninitialized to give diagnostic message.  "submodule update"
> without pathspec is supposed to iterate over all submodules
> (i.e. without pathspec limitation) and update only the
> initialized submodules, and finding uninitialized submodules
> during the iteration is a totally expected and normal thing that
> should not be warned.
>
> Signed-off-by: Orgad Shaneh <orgads@gmail.com>
> ---
>     submodule--helper: fix initialization of warn_if_uninitialized
>     
>     The .warn_if_uninitialized member was introduced by 48308681 (git
>     submodule update: have a dedicated helper for cloning, 2016-02-29) to
>     submodule_update_clone struct and initialized to false. When c9911c93
>     (submodule--helper: teach update_data more options, 2022-03-15) moved it
>     to update_data struct, it started to initialize it to true but this
>     change was not explained in its log message.
>     
>     The member is set to true only when pathspec was given, and is used when
>     a submodule that matched the pathspec is found uninitialized to give
>     diagnostic message. "submodule update" without pathspec is supposed to
>     iterate over all submodules (i.e. without pathspec limitation) and
>     update only the initialized submodules, and finding uninitialized
>     submodules during the iteration is a totally expected and normal thing
>     that should not be warned.
>     
>     Signed-off-by: Orgad Shaneh orgads@gmail.com
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1258%2Forgads%2Fsub-no-warn-v2
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1258/orgads/sub-no-warn-v2
> Pull-Request: https://github.com/git/git/pull/1258
>
> Range-diff vs v1:
>
>  1:  089a52a50b4 ! 1:  1e34c9cad18 submodule--helper: fix initialization of warn_if_uninitialized
>      @@ Metadata
>        ## Commit message ##
>           submodule--helper: fix initialization of warn_if_uninitialized
>       
>      -    This field is supposed to be off by default, and it is only enabled when
>      -    running `git submodule update <path>`, and path is not initialized.
>      +    The .warn_if_uninitialized member was introduced by 48308681
>      +    (git submodule update: have a dedicated helper for cloning,
>      +    2016-02-29) to submodule_update_clone struct and initialized to
>      +    false.  When c9911c93 (submodule--helper: teach update_data more
>      +    options, 2022-03-15) moved it to update_data struct, it started
>      +    to initialize it to true but this change was not explained in
>      +    its log message.
>       
>      -    Commit c9911c9358 changed it to enabled by default. This affects for
>      -    example git checkout, which displays the following warning for each
>      -    uninitialized submodule:
>      -
>      -    Submodule path 'sub' not initialized
>      -    Maybe you want to use 'update --init'?
>      -
>      -    Amends c9911c9358e611390e2444f718c73900d17d3d60.
>      +    The member is set to true only when pathspec was given, and is
>      +    used when a submodule that matched the pathspec is found
>      +    uninitialized to give diagnostic message.  "submodule update"
>      +    without pathspec is supposed to iterate over all submodules
>      +    (i.e. without pathspec limitation) and update only the
>      +    initialized submodules, and finding uninitialized submodules
>      +    during the iteration is a totally expected and normal thing that
>      +    should not be warned.
>       
>           Signed-off-by: Orgad Shaneh <orgads@gmail.com>
>       
>      @@ builtin/submodule--helper.c: struct update_data {
>        	.single_branch = -1, \
>        	.max_jobs = 1, \
>       -	.warn_if_uninitialized = 1, \
>      -+	.warn_if_uninitialized = 0, \
>        }
>        
>        static void next_submodule_warn_missing(struct submodule_update_clone *suc,
>
>
>  builtin/submodule--helper.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> index 2c87ef9364f..1a8e5d06214 100644
> --- a/builtin/submodule--helper.c
> +++ b/builtin/submodule--helper.c
> @@ -2026,7 +2026,6 @@ struct update_data {
>  	.references = STRING_LIST_INIT_DUP, \
>  	.single_branch = -1, \
>  	.max_jobs = 1, \
> -	.warn_if_uninitialized = 1, \
>  }
>  
>  static void next_submodule_warn_missing(struct submodule_update_clone *suc,
>
> base-commit: 6cd33dceed60949e2dbc32e3f0f5e67c4c882e1e
> -- 
> gitgitgadget

This was clearly a mistake on my part :( The fix looks good to me,
thanks!
Glen Choo April 27, 2022, 10:22 p.m. UTC | #4
Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Is this a fix we can protect from future breakge by adding a test or
>> tweaking an existing test?  It is kind of surprising if we did not
>> have any test that runs "git submodule update" in a superproject
>> with initialized and uninitialized submodule(s) and make sure only
>> the initialized ones are updated.  It may be the matter of examining
>> the warning output that is currently ignored in such a test, if
>> there is one.
>
> Here is a quick-and-dirty one I came up with.  The superproject
> "super" has a handful of submodules ("submodule" and "rebasing"
> being two of them), so the new tests clone the superproject and
> initializes only one submodule.  Then we see how "submodule update"
> with pathspec works with these two submodules (one initialied and
> the other not).  In another test, we see how "submodule update"
> without pathspec works.
>
> I'll queue this on top of your fix for now tentatively.  If nobody
> finds flaws in them, I'll just squash it in soonish before merging
> the whole thing for the maintenance track.
>
> Thanks.

Thanks for adding the tests!

>  t/t7406-submodule-update.sh | 33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
>
> diff --git c/t/t7406-submodule-update.sh w/t/t7406-submodule-update.sh
> index 000e055811..43f779d751 100755
> --- c/t/t7406-submodule-update.sh
> +++ w/t/t7406-submodule-update.sh
> @@ -670,6 +670,39 @@ test_expect_success 'submodule update --init skips submodule with update=none' '
>  	)
>  '
>  
> +test_expect_success 'submodule update with pathspec warns against uninitialized ones' '
> +	test_when_finished "rm -fr selective" &&
> +	git clone super selective &&
> +	(
> +		cd selective &&
> +		git submodule init submodule &&
> +
> +		git submodule update submodule 2>err &&
> +		! grep "Submodule path .* not initialized" err &&
> +
> +		git submodule update rebasing 2>err &&
> +		grep "Submodule path .rebasing. not initialized" err &&
> +
> +		test_path_exists submodule/.git &&
> +		test_path_is_missing rebasing/.git
> +	)
> +
> +'
> +
> +test_expect_success 'submodule update without pathspec updates only initialized ones' '
> +	test_when_finished "rm -fr selective" &&
> +	git clone super selective &&
> +	(
> +		cd selective &&
> +		git submodule init submodule &&
> +		git submodule update 2>err &&
> +		test_path_exists submodule/.git &&
> +		test_path_is_missing rebasing/.git &&
> +		! grep "Submodule path .* not initialized" err
> +	)
> +
> +'
> +
>  test_expect_success 'submodule update continues after checkout error' '
>  	(cd super &&
>  	 git reset --hard HEAD &&

So we test that we only issue the warning when a pathspec is given, and
that we ignore uninitialized submodules when no pathspec is given. I
think this covers all of the cases, so this looks good, thanks!
Glen Choo April 27, 2022, 10:23 p.m. UTC | #5
Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Is this a fix we can protect from future breakge by adding a test or
>> tweaking an existing test?  It is kind of surprising if we did not
>> have any test that runs "git submodule update" in a superproject
>> with initialized and uninitialized submodule(s) and make sure only
>> the initialized ones are updated.  It may be the matter of examining
>> the warning output that is currently ignored in such a test, if
>> there is one.
>
> Here is a quick-and-dirty one I came up with.  The superproject
> "super" has a handful of submodules ("submodule" and "rebasing"
> being two of them), so the new tests clone the superproject and
> initializes only one submodule.  Then we see how "submodule update"
> with pathspec works with these two submodules (one initialied and
> the other not).  In another test, we see how "submodule update"
> without pathspec works.
>
> I'll queue this on top of your fix for now tentatively.  If nobody
> finds flaws in them, I'll just squash it in soonish before merging
> the whole thing for the maintenance track.
>
> Thanks.

Thanks for adding the tests!

>  t/t7406-submodule-update.sh | 33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
>
> diff --git c/t/t7406-submodule-update.sh w/t/t7406-submodule-update.sh
> index 000e055811..43f779d751 100755
> --- c/t/t7406-submodule-update.sh
> +++ w/t/t7406-submodule-update.sh
> @@ -670,6 +670,39 @@ test_expect_success 'submodule update --init skips submodule with update=none' '
>  	)
>  '
>  
> +test_expect_success 'submodule update with pathspec warns against uninitialized ones' '
> +	test_when_finished "rm -fr selective" &&
> +	git clone super selective &&
> +	(
> +		cd selective &&
> +		git submodule init submodule &&
> +
> +		git submodule update submodule 2>err &&
> +		! grep "Submodule path .* not initialized" err &&
> +
> +		git submodule update rebasing 2>err &&
> +		grep "Submodule path .rebasing. not initialized" err &&
> +
> +		test_path_exists submodule/.git &&
> +		test_path_is_missing rebasing/.git
> +	)
> +
> +'
> +
> +test_expect_success 'submodule update without pathspec updates only initialized ones' '
> +	test_when_finished "rm -fr selective" &&
> +	git clone super selective &&
> +	(
> +		cd selective &&
> +		git submodule init submodule &&
> +		git submodule update 2>err &&
> +		test_path_exists submodule/.git &&
> +		test_path_is_missing rebasing/.git &&
> +		! grep "Submodule path .* not initialized" err
> +	)
> +
> +'
> +
>  test_expect_success 'submodule update continues after checkout error' '
>  	(cd super &&
>  	 git reset --hard HEAD &&

So we test that we only issue the warning when a pathspec is given, and
that we ignore uninitialized submodules when no pathspec is given. I
think this covers all of the cases, so this looks good, thanks!
Glen Choo April 27, 2022, 10:25 p.m. UTC | #6
Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Is this a fix we can protect from future breakge by adding a test or
>> tweaking an existing test?  It is kind of surprising if we did not
>> have any test that runs "git submodule update" in a superproject
>> with initialized and uninitialized submodule(s) and make sure only
>> the initialized ones are updated.  It may be the matter of examining
>> the warning output that is currently ignored in such a test, if
>> there is one.
>
> Here is a quick-and-dirty one I came up with.  The superproject
> "super" has a handful of submodules ("submodule" and "rebasing"
> being two of them), so the new tests clone the superproject and
> initializes only one submodule.  Then we see how "submodule update"
> with pathspec works with these two submodules (one initialied and
> the other not).  In another test, we see how "submodule update"
> without pathspec works.
>
> I'll queue this on top of your fix for now tentatively.  If nobody
> finds flaws in them, I'll just squash it in soonish before merging
> the whole thing for the maintenance track.
>
> Thanks.

Thanks for adding the tests!

>  t/t7406-submodule-update.sh | 33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
>
> diff --git c/t/t7406-submodule-update.sh w/t/t7406-submodule-update.sh
> index 000e055811..43f779d751 100755
> --- c/t/t7406-submodule-update.sh
> +++ w/t/t7406-submodule-update.sh
> @@ -670,6 +670,39 @@ test_expect_success 'submodule update --init skips submodule with update=none' '
>  	)
>  '
>  
> +test_expect_success 'submodule update with pathspec warns against uninitialized ones' '
> +	test_when_finished "rm -fr selective" &&
> +	git clone super selective &&
> +	(
> +		cd selective &&
> +		git submodule init submodule &&
> +
> +		git submodule update submodule 2>err &&
> +		! grep "Submodule path .* not initialized" err &&
> +
> +		git submodule update rebasing 2>err &&
> +		grep "Submodule path .rebasing. not initialized" err &&
> +
> +		test_path_exists submodule/.git &&
> +		test_path_is_missing rebasing/.git
> +	)
> +
> +'
> +
> +test_expect_success 'submodule update without pathspec updates only initialized ones' '
> +	test_when_finished "rm -fr selective" &&
> +	git clone super selective &&
> +	(
> +		cd selective &&
> +		git submodule init submodule &&
> +		git submodule update 2>err &&
> +		test_path_exists submodule/.git &&
> +		test_path_is_missing rebasing/.git &&
> +		! grep "Submodule path .* not initialized" err
> +	)
> +
> +'
> +
>  test_expect_success 'submodule update continues after checkout error' '
>  	(cd super &&
>  	 git reset --hard HEAD &&

So we test that we only issue the warning when a pathspec is given, and
that we ignore uninitialized submodules when no pathspec is given. I
think this covers all of the cases, so this looks good, thanks!
Junio C Hamano April 27, 2022, 11:20 p.m. UTC | #7
Glen Choo <chooglen@google.com> writes:

> "Orgad Shaneh via GitGitGadget" <gitgitgadget@gmail.com> writes:
>> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
>> index 2c87ef9364f..1a8e5d06214 100644
>> --- a/builtin/submodule--helper.c
>> +++ b/builtin/submodule--helper.c
>> @@ -2026,7 +2026,6 @@ struct update_data {
>>  	.references = STRING_LIST_INIT_DUP, \
>>  	.single_branch = -1, \
>>  	.max_jobs = 1, \
>> -	.warn_if_uninitialized = 1, \
>>  }
>>  
>>  static void next_submodule_warn_missing(struct submodule_update_clone *suc,
>>
>> base-commit: 6cd33dceed60949e2dbc32e3f0f5e67c4c882e1e
>> -- 
>> gitgitgadget
>
> This was clearly a mistake on my part :( The fix looks good to me,
> thanks!

Will merge the fix down in preparation for 2.36.1 and later.

Thanks, both.
diff mbox series

Patch

diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 2c87ef9364f..1a8e5d06214 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -2026,7 +2026,6 @@  struct update_data {
 	.references = STRING_LIST_INIT_DUP, \
 	.single_branch = -1, \
 	.max_jobs = 1, \
-	.warn_if_uninitialized = 1, \
 }
 
 static void next_submodule_warn_missing(struct submodule_update_clone *suc,