From: Glen Choo <chooglen@google.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>, git@vger.kernel.org
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Jonas Bernoulli" <jonas@bernoul.li>, "Jeff King" <peff@peff.net>,
"Emily Shaffer" <emilyshaffer@google.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH 06/10] git-submodule.sh: don't support top-level "--cached"
Date: Thu, 20 Oct 2022 15:14:44 -0700 [thread overview]
Message-ID: <kl6lsfjixhuz.fsf@chooglen-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <patch-06.10-25fadf3ffc1-20221017T115544Z-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Since the preceding commit all sub-commands of "git submodule" have
> been dispatched to "git submodule--helper" directly, we therefore
> don't need to emit "usage()" if we see "--cached" without the
> sub-command being "status" or "summary", we can trust that
> parse_options() will spot that and barf on it.
>
> This does change one obscure aspect of undocumented behavior, for
> "status" and "summary" we supported these undocumented forms:
>
> git submodule --cached (status | summary)
>
> As noted in a preceding commit to git-submodule.sh which removed the
> "--branch" special-case, this comes down to emergent behavior seen in
> 5c08dbbdf1a (git-submodule: fix subcommand parser,
> 2008-01-15). I.e. we wanted to support was for subcommand-less invocations like:
>
> git submodule --cached
>
> To be synonymous with invocations that explicitly named the "status"
> sub-command:
>
> git submodule status --cached
>
> But we did not intend to mix the two, and allow "--cached" to be an
> option to the top-level "submodule" command when the "status" or
> "summary" sub-commands were explicitly provided.
>
> Let's remove this undocumented edge case, which makes a subsequent
> removal of git-submodule.sh easier to reason about. The test case
> added here is duplicated from the existing for-loop, except for the
> different and desired handling of "git submodule --cached status".
Makes sense, I completely agree.
> diff --git a/git-submodule.sh b/git-submodule.sh
> index ac2f95c1285..4f8f62ce981 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -43,7 +43,14 @@ do
> quiet=1
> ;;
> --cached)
> - cached=1
> + if test -z "$command"
> + then
> + cached=1 &&
> + shift &&
> + break
> + else
> + usage
> + fi
> ;;
> --)
> break
Do we need the 'if test -z "$command"'? This is in a 'while test $# != 0
&& test -z "$command"' loop, so it seems unnecessary. I've tried
removing it and it seems to work just fine.
> @@ -69,12 +76,6 @@ then
> fi
> fi
>
> -# "--cached" is accepted only by "status" and "summary"
> -if test -n "$cached" && test "$command" != status && test "$command" != summary
> -then
> - usage
> -fi
> -
> case "$command" in
> absorbgitdirs)
> git submodule--helper "$command" --prefix "$wt_prefix" "$@"
> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> index b50db3f1031..d8f7d6ee29a 100755
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
> @@ -31,7 +31,7 @@ test_expect_success 'submodule usage: status --' '
> test_expect_code 1 git submodule --end-of-options
> '
>
> -for opt in '--quiet' '--cached'
> +for opt in '--quiet'
> do
> test_expect_success "submodule usage: status $opt" '
> git submodule $opt &&
> @@ -40,6 +40,17 @@ do
> '
> done
>
> +for opt in '--cached'
> +do
> + test_expect_success "submodule usage: status $opt" '
> + git submodule $opt &&
> + git submodule status $opt &&
> + test_expect_code 1 git submodule $opt status >out 2>err &&
> + grep "^usage: git submodule" err &&
> + test_must_be_empty out
> + '
> +done
> +
Now that there's only a single opt in each of these tests, do we still
want to keep the for loop?
> test_expect_success 'submodule deinit works on empty repository' '
> git submodule deinit --all
> '
> @@ -576,7 +587,7 @@ test_expect_success 'status should be "modified" after submodule commit' '
> '
>
> test_expect_success 'the --cached sha1 should be rev1' '
> - git submodule --cached status >list &&
> + git submodule status --cached >list &&
> grep "^+$rev1" list
> '
>
> --
> 2.38.0.1091.gf9d18265e59
next prev parent reply other threads:[~2022-10-20 22:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-17 12:09 [PATCH 00/10] submodule: make it a built-in, remove git-submodule.sh Ævar Arnfjörð Bjarmason
2022-10-17 12:09 ` [PATCH 01/10] git-submodule.sh: create a "case" dispatch statement Ævar Arnfjörð Bjarmason
2022-10-17 12:09 ` [PATCH 02/10] git-submodule.sh: dispatch "sync" to helper Ævar Arnfjörð Bjarmason
2022-10-20 20:42 ` Glen Choo
2022-10-17 12:09 ` [PATCH 03/10] git-submodule.sh: dispatch directly " Ævar Arnfjörð Bjarmason
2022-10-17 12:09 ` [PATCH 04/10] git-submodule.sh: dispatch "foreach" " Ævar Arnfjörð Bjarmason
2022-10-20 21:14 ` Glen Choo
2022-10-17 12:09 ` [PATCH 05/10] git-submodule.sh: dispatch "update" " Ævar Arnfjörð Bjarmason
2022-10-20 21:50 ` Glen Choo
2022-10-17 12:09 ` [PATCH 06/10] git-submodule.sh: don't support top-level "--cached" Ævar Arnfjörð Bjarmason
2022-10-20 22:14 ` Glen Choo [this message]
2022-10-17 12:09 ` [PATCH 07/10] submodule: make it a built-in, remove git-submodule.sh Ævar Arnfjörð Bjarmason
2022-10-20 22:49 ` Glen Choo
2022-10-17 12:09 ` [PATCH 08/10] submodule: support "--" with no other arguments Ævar Arnfjörð Bjarmason
2022-10-17 12:09 ` [PATCH 09/10] submodule: support sub-command-less "--recursive" option Ævar Arnfjörð Bjarmason
2022-10-20 23:05 ` Glen Choo
2022-10-17 12:09 ` [PATCH 10/10] submodule: don't use a subprocess to invoke "submodule--helper" Ævar Arnfjörð Bjarmason
2022-10-20 23:18 ` Glen Choo
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=kl6lsfjixhuz.fsf@chooglen-macbookpro.roam.corp.google.com \
--to=chooglen@google.com \
--cc=avarab@gmail.com \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jonas@bernoul.li \
--cc=peff@peff.net \
/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.
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).