git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Theodore Dubois <tbodt@google.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Propagate --quiet on submodule update to merge/rebase
Date: Wed, 30 Sep 2020 12:24:04 -0700	[thread overview]
Message-ID: <xmqqft6zgjaj.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200930074729.99629-1-tbodt@google.com> (Theodore Dubois's message of "Wed, 30 Sep 2020 00:47:30 -0700")

Theodore Dubois <tbodt@google.com> writes:

> Without this, commands such as
> git pull --rebase --recurse-submodules --quiet
> might produce non-quiet output from the merge or rebase.
>
> Signed-off-by: Theodore Dubois <tbodt@google.com>
> ---
>  git-submodule.sh            | 4 ++--
>  t/t7406-submodule-update.sh | 9 +++++++++
>  2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git git-submodule.sh git-submodule.sh
> index 6fb12585cb..5c22b17221 100755
> --- git-submodule.sh
> +++ git-submodule.sh
> @@ -614,13 +614,13 @@ cmd_update()
>  				say_msg="$(eval_gettext "Submodule path '\$displaypath': checked out '\$sha1'")"
>  				;;
>  			rebase)
> -				command="git rebase"
> +				command="git rebase ${GIT_QUIET:+--quiet}"
>  				die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$displaypath'")"
>  				say_msg="$(eval_gettext "Submodule path '\$displaypath': rebased into '\$sha1'")"
>  				must_die_on_failure=yes
>  				;;
>  			merge)
> -				command="git merge"
> +				command="git merge ${GIT_QUIET:+--quiet}"
>  				die_msg="$(eval_gettext "Unable to merge '\$sha1' in submodule path '\$displaypath'")"
>  				say_msg="$(eval_gettext "Submodule path '\$displaypath': merged in '\$sha1'")"
>  				must_die_on_failure=yes

This is not the problem this patch introduces, but the way GIT_QUIET
variable is set up does not allow us to do the above so nicely, I
suspect.  Wouldn't the above change make "git submodule update -v"
invoke the underlying commands with "--quiet" option?


The problematic piece of code is this part:

        cmd_update()
        {
                # parse $args after "submodule ... update".
                while test $# -ne 0
                do
                        case "$1" in
                        -q|--quiet)
                                GIT_QUIET=1
                                ;;
                        -v)
                                GIT_QUIET=0
                                ;;
                        --progress)
                                progress=1
                                ;;


I think this is the only place in the script that GIT_QUIET is set
to 0, but all the places that refer to the variable do not even
check the value held in it.  Makes me wonder if it was used
differently back when e84c3cf3dc3 was written.

    ... goes and looks at the offending commit ...

I think the right fix could have been "unset GIT_QUIET" instead of
assigning 0 that means the same thing as GIT_QUIET=1

In any case, the posted patch is a good first step but it makes the
existing problem worse.  Let's fix GIT_QUIET=0 at the same time.

Thanks.

> diff --git t/t7406-submodule-update.sh t/t7406-submodule-update.sh
> index aa19ff3a2e..5213e47af8 100755
> --- t/t7406-submodule-update.sh
> +++ t/t7406-submodule-update.sh
> @@ -1022,4 +1022,13 @@ test_expect_success 'git clone passes the parallel jobs config on to submodules'
>  	rm -rf super4
>  '
>  
> +test_expect_success 'submodule update --quiet passes quietness to merge/rebase' '
> +	(cd super &&
> +	 test_commit -C rebasing message &&
> +	 git submodule update --rebase --quiet >out 2>err &&

IOW, I suspect that this test will still pass with s/--quiet/-v/ .

> +	 test_must_be_empty out &&
> +	 test_must_be_empty err
> +	)
> +'


  reply	other threads:[~2020-09-30 19:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30  7:47 [PATCH] Propagate --quiet on submodule update to merge/rebase Theodore Dubois
2020-09-30 19:24 ` Junio C Hamano [this message]
2020-09-30 19:44   ` Theodore Dubois
2020-09-30 20:34     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqft6zgjaj.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=tbodt@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).