Re: [PATCH] Let submodule command exit with error status if path does not exist

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 9, 2012, 20:42 UTC
Message-ID: <7vboijol03.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120809200302.GA93203@book.hvoigt.net>

Heiko Voigt <hvoigt@hvoigt.net> writes:

Show 7 quoted lines

> Previously the exit status of git submodule was zero for various
> subcommands even though the user specified an unknown path.
>
> The reason behind that was that they all pipe the output of module_list
> into the while loop which then does the action on the paths specified by
> the commandline. Since piped commands are run in parallel the status
> code of module_list was swallowed.

It is more like that the shell ignores the exit status of command that is on the upstream side of a pipeline.

> We work around this by introducing a new function module_list_valid
> which is used to check the leftover commandline parameters passed to
> module_list.

Doesn't it slow things down for the normal case, though?

A plausible hack, assuming all the problematic readers of the pipe are of the form "... | while read mode sha1 stage sm_path", might be to update module_list () to do something like:

	(
		git ls-files --error-unmatch ... ||
                echo "#unmatched"
	)

and then update the readers to catch "#unmatched" token, e.g.

	module_list "$@" |
        while read mode sha1 stage sm_path
        do
		if test "$mode" = "#unmatched"
                then
        		... do the necessary error thing ...
                        continue
		fi
                ... whatever the loop originally did ...
	done

One thing to note is that the above is not good if you want to atomically reject

	git submodule foo module1 moduel2

and error the whole thing out without touching module1 (which exists) because of misspelt module2.

But is it what we want to see happen in these codepaths?

Show 16 quoted lines

> diff --git a/git-submodule.sh b/git-submodule.sh
> index aac575e..1fd21da 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -103,13 +103,21 @@ resolve_relative_url ()
>  	echo "${is_relative:+${up_path}}${remoteurl#./}"
>  }
>  
> +module_list_ls_files() {
> +	git ls-files --error-unmatch --stage -- "$@"
> +}
> +
> +module_list_valid() {
> +	module_list_ls_files "$@" >/dev/null
> +}
> +

This is a tangent, but among the 170 hits

	git grep -e '^[a-z][a-z0-9A-Z_]* *(' -- './git-*.sh'

gives, about 120 have SP after funcname, i.e.

	funcname () {

and 50 don't, i.e.

	funcname() {

This file has 12 such definitions, among which 10 are the latter form. There is no "rational" reason to choose between the two, but having two forms in the same project hurts greppability. Updating the style of existing code shouldn't be done in the same patch, but please do not make things worse.

Show 9 quoted lines

> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> index c73bec9..3a40334 100755
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
> @@ -258,6 +258,27 @@ test_expect_success 'init should register submodule url in .git/config' '
>  	test_cmp expect url
>  '
>  
> +test_failure_with_unknown_submodule() {

Likewise, even though inside t/ directory we seem to have more offenders (190/480 ~ 40%, vs 50/170 ~ 30%).

> +	test_must_fail git submodule $1 no-such-submodule 2>output.err &&
> +	grep "^error: .*no-such-submodule" output.err
> +}

I think the latter half already passes with the current code, but the exit code from "git submodule $1" would be corrected with this patch, which is good.

Thanks.