[PATCH 1/3] t7406-submodule-update: add missing &&

[PATCH 1/3] t7406-submodule-update: add missing &&

[Tay Ray Chuan]

322bb6e (2011 Aug 11) introduced a new subshell at the end of a test
case but omitted a '&&' to join the two; fix this.

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
 t/t7406-submodule-update.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index b192f93..f0b3305 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -58,7 +58,7 @@ test_expect_success 'setup a submodule tree' '
 	 git submodule add ../merging merging &&
 	 test_tick &&
 	 git commit -m "rebasing"
-	)
+	) &&
 	(cd super &&
 	 git submodule add ../none none &&
 	 test_tick &&
-- 
1.8.4.rc4.527.g303b16c

[PATCH 2/3] t7406-submodule-update: demonstrate behaviour when run without init beforehand

[Tay Ray Chuan]

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
 t/t7406-submodule-update.sh | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index f0b3305..00475eb 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -66,6 +66,26 @@ test_expect_success 'setup a submodule tree' '
 	)
 '
 
+test_expect_success 'setup a repo with uninitialized submodules' '
+	git clone super super2
+'
+
+test_expect_success 'submodule update <path> warns without init beforehand' '
+	(cd super2 &&
+	 test -n "$(git submodule update submodule)"
+	)
+'
+
+test_expect_success 'submodule update is silent without init beforehand' '
+	(cd super2 &&
+	 test -z "$(git submodule update)"
+	)
+'
+
+test_expect_success 'cleanup repo with uninitialized submodules' '
+	rm -rf super2
+'
+
 test_expect_success 'submodule update detaching the HEAD ' '
 	(cd super/submodule &&
 	 git reset --hard HEAD~1
-- 
1.8.4.rc4.527.g303b16c

[PATCH 3/3] git submodule update should give notice when run without init beforehand

[Tay Ray Chuan]

When 'update' is run with no path in a repository with uninitialized
submodules, the program terminates with no output, and zero status code.
Be more helpful to users by mentioning this.

This may be controlled by an advice.* option.

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
 Documentation/config.txt    |  5 +++++
 git-submodule.sh            | 16 ++++++++++++++--
 t/t7406-submodule-update.sh |  5 ++++-
 3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index ec57a15..79313f9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -202,6 +202,11 @@ advice.*::
 	rmHints::
 		In case of failure in the output of linkgit:git-rm[1],
 		show directions on how to proceed from the current state.
+	submoduleUpdateUninit::
+		When linkgit:git-submodule[1] `update` is run with no `path`
+		arguments in a repository with uninitialized submodules,
+		mention that uninitalized submodules are indeed present, and
+		that they may be initialized with the `--init` option.
 --
 
 core.fileMode::
diff --git a/git-submodule.sh b/git-submodule.sh
index 2979197..56f3dc2 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -777,6 +777,7 @@ cmd_update()
 	cloned_modules=
 	module_list "$@" | {
 	err=
+	has_uninit=
 	while read mode sha1 stage sm_path
 	do
 		die_if_unmatched "$mode"
@@ -807,9 +808,13 @@ cmd_update()
 		then
 			# Only mention uninitialized submodules when its
 			# path have been specified
-			test "$#" != "0" &&
-			say "$(eval_gettext "Submodule path '\$displaypath' not initialized
+			if test "$#" != "0"
+			then
+				say "$(eval_gettext "Submodule path '\$displaypath' not initialized
 Maybe you want to use 'update --init'?")"
+			else
+				has_uninit=1
+			fi
 			continue
 		fi
 
@@ -940,6 +945,13 @@ Maybe you want to use 'update --init'?")"
 		IFS=$OIFS
 		exit 1
 	fi
+
+	if test -n "$has_uninit" \
+		-a "$(git config --bool --get advice.submoduleUpdateUninit)" != "false"
+	then
+		say "$(eval_gettext "Uninitialized submodules were detected;
+Maybe you want to use 'update --init'?")"
+	fi
 	}
 }
 
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 00475eb..8dbe410 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -76,8 +76,11 @@ test_expect_success 'submodule update <path> warns without init beforehand' '
 	)
 '
 
-test_expect_success 'submodule update is silent without init beforehand' '
+test_expect_success 'submodule update warns without init beforehand' '
 	(cd super2 &&
+	 test_must_fail git config --get advice.submoduleUpdateUninit &&
+	 test -n "$(git submodule update)" &&
+	 git config advice.submoduleUpdateUninit false &&
 	 test -z "$(git submodule update)"
 	)
 '
-- 
1.8.4.rc4.527.g303b16c

Re: [PATCH 3/3] git submodule update should give notice when run without init beforehand

[Jens Lehmann]

Am 15.09.2013 19:38, schrieb Tay Ray Chuan:
> When 'update' is run with no path in a repository with uninitialized
> submodules, the program terminates with no output, and zero status code.
> Be more helpful to users by mentioning this.

Hmm, this patch is changing the default behavior, right? I assume the
motivation for this patch is to help people who tend to forget to init
submodules they need to have checked out, which is a good idea. But I
think this should not be enabled by default, as in a lot of use cases
one or more uninitialized submodules are present on purpose. In those
use cases it would be rather nasty to error out on every submodule
update.

After the 'autoinit' configuration (which lets upstream hint that
certain submodules should be initialized on clone) has materialzed we
might want to enable this error for these specific submodules. But in
any case the error message should contain a hint on how you can get
rid of the error in case you know what you are doing ;-).

> This may be controlled by an advice.* option.
>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
> ---
>  Documentation/config.txt    |  5 +++++
>  git-submodule.sh            | 16 ++++++++++++++--
>  t/t7406-submodule-update.sh |  5 ++++-
>  3 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index ec57a15..79313f9 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -202,6 +202,11 @@ advice.*::
>  	rmHints::
>  		In case of failure in the output of linkgit:git-rm[1],
>  		show directions on how to proceed from the current state.
> +	submoduleUpdateUninit::
> +		When linkgit:git-submodule[1] `update` is run with no `path`
> +		arguments in a repository with uninitialized submodules,
> +		mention that uninitalized submodules are indeed present, and
> +		that they may be initialized with the `--init` option.
>  --
>  
>  core.fileMode::
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 2979197..56f3dc2 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -777,6 +777,7 @@ cmd_update()
>  	cloned_modules=
>  	module_list "$@" | {
>  	err=
> +	has_uninit=
>  	while read mode sha1 stage sm_path
>  	do
>  		die_if_unmatched "$mode"
> @@ -807,9 +808,13 @@ cmd_update()
>  		then
>  			# Only mention uninitialized submodules when its
>  			# path have been specified
> -			test "$#" != "0" &&
> -			say "$(eval_gettext "Submodule path '\$displaypath' not initialized
> +			if test "$#" != "0"
> +			then
> +				say "$(eval_gettext "Submodule path '\$displaypath' not initialized
>  Maybe you want to use 'update --init'?")"
> +			else
> +				has_uninit=1
> +			fi
>  			continue
>  		fi
>  
> @@ -940,6 +945,13 @@ Maybe you want to use 'update --init'?")"
>  		IFS=$OIFS
>  		exit 1
>  	fi
> +
> +	if test -n "$has_uninit" \
> +		-a "$(git config --bool --get advice.submoduleUpdateUninit)" != "false"
> +	then
> +		say "$(eval_gettext "Uninitialized submodules were detected;
> +Maybe you want to use 'update --init'?")"
> +	fi
>  	}
>  }
>  
> diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
> index 00475eb..8dbe410 100755
> --- a/t/t7406-submodule-update.sh
> +++ b/t/t7406-submodule-update.sh
> @@ -76,8 +76,11 @@ test_expect_success 'submodule update <path> warns without init beforehand' '
>  	)
>  '
>  
> -test_expect_success 'submodule update is silent without init beforehand' '
> +test_expect_success 'submodule update warns without init beforehand' '
>  	(cd super2 &&
> +	 test_must_fail git config --get advice.submoduleUpdateUninit &&
> +	 test -n "$(git submodule update)" &&
> +	 git config advice.submoduleUpdateUninit false &&
>  	 test -z "$(git submodule update)"
>  	)
>  '
> 

Re: [PATCH 3/3] git submodule update should give notice when run without init beforehand

[Tay Ray Chuan]

On Tue, Sep 17, 2013 at 1:06 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:

Thanks Jens for having a look!

> Am 15.09.2013 19:38, schrieb Tay Ray Chuan:
>> When 'update' is run with no path in a repository with uninitialized
>> submodules, the program terminates with no output, and zero status code.
>> Be more helpful to users by mentioning this.
>
> [snip] it would be rather nasty to error out on every submodule
> update.

Just to be sure we're on the right page, with this patch, the 'update'
command still exits with status code zero (non-error), so this patch
doesn't make it error out.

> After the 'autoinit' configuration (which lets upstream hint that
> certain submodules should be initialized on clone) has materialzed we
> might want to enable this error for these specific submodules.

That's cool, I'm looking forward to this. Could you point me to
somewhere detailing this?

But in the meantime, on top of the advice.* config, how about having a
submodule.<name>.ignoreUninit config to disable the message on a
per-submodule basis?

> But in
> any case the error message should contain a hint on how you can get
> rid of the error in case you know what you are doing ;-).

The message does mention that you can throw in an --init to fix the
problem. This "hint" is similar to what git-submodule prints when a
<path> is passed (see region at line 807).

-- 
Cheers,
Ray Chuan

Re: [PATCH 3/3] git submodule update should give notice when run without init beforehand

[Jens Lehmann]

Am 18.09.2013 12:12, schrieb Tay Ray Chuan:
> On Tue, Sep 17, 2013 at 1:06 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> 
> Thanks Jens for having a look!
> 
>> Am 15.09.2013 19:38, schrieb Tay Ray Chuan:
>>> When 'update' is run with no path in a repository with uninitialized
>>> submodules, the program terminates with no output, and zero status code.
>>> Be more helpful to users by mentioning this.
>>
>> [snip] it would be rather nasty to error out on every submodule
>> update.
> 
> Just to be sure we're on the right page, with this patch, the 'update'
> command still exits with status code zero (non-error), so this patch
> doesn't make it error out.

Ok, sorry for the confusion. But I still think we should not change
the default to print these messages, but make it an opt-in. And the
commit message (and maybe the documentation too) should talk about
the use cases where this makes sense.

>> After the 'autoinit' configuration (which lets upstream hint that
>> certain submodules should be initialized on clone) has materialzed we
>> might want to enable this error for these specific submodules.
> 
> That's cool, I'm looking forward to this. Could you point me to
> somewhere detailing this?

Not yet. I'm still wrestling with the autoupdate series, which is
the logical step before autoinit. autoupdate enables to configure
that initialized submodules are updated on checkout, reset, merge
and all the other work tree manipulating commands. autoinit then
also clones the repos of submodules into .git/modules and inits
them in .git/config, so that autoupdate will automagically populate
them. Unfortunately autoupdate is a rather largish series touching
lots of commands and needing tons of tests ...

> But in the meantime, on top of the advice.* config, how about having a
> submodule.<name>.ignoreUninit config to disable the message on a
> per-submodule basis?

I'd not add such an option unless users request it because it helps
their not-so-terribly-specific use case.

>> But in
>> any case the error message should contain a hint on how you can get
>> rid of the error in case you know what you are doing ;-).
> 
> The message does mention that you can throw in an --init to fix the
> problem. This "hint" is similar to what git-submodule prints when a
> <path> is passed (see region at line 807).

But for a lot of users that isn't a solution, as they never want to
init it, they want to ignore it. And if you explicitly ask to update
a special submodule, that message is ok.

Re: [PATCH 3/3] git submodule update should give notice when run without init beforehand

[Chris Packham]

On 18/09/13 22:22, Tay Ray Chuan wrote:
> Hi Chris,
> 
> I think you mentioned usability issues with git-submodule before on
> the git mailing list, so I thought you might be interested in taking a
> look at this patch. It's attached below, you can also view it at
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/1379266703-29808-3-git-send-email-rctay89@gmail.com
> 
> I would be interested in hearing what you think.
> 

The case I had was that an un-init'd submodule was still a directory on
the file system so 'cd submodule' would work and it could go unnoticed
that we hadn't entered the submodule.

Your change might have helped somewhat but the bigger problem was that
the work-tree representation of an un-init'd submodule is a directory.
There was never any thought to actually run 'git submodule update'
because the developer in question thought they already had.

I think Jens' autoinit may be the right direction. It certainly would be
what we'd want for our use-case at $dayjob.