From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: Jens.Lehmann@web.de, git@vger.kernel.org
Subject: Re: [PATCH 2/3] submodule deinit: lose requirement for giving '.'
Date: Tue, 03 May 2016 10:21:18 -0700 [thread overview]
Message-ID: <xmqqoa8nnjld.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1462227844-10624-3-git-send-email-sbeller@google.com> (Stefan Beller's message of "Mon, 2 May 2016 15:24:03 -0700")
Stefan Beller <sbeller@google.com> writes:
> The discussion in [1] realized that '.' is a faulty suggestion as
> there is a corner case where it fails:
>
>> "submodule deinit ." may have "worked" in the sense that you would
>> have at least one path in your tree and avoided this "nothing
>> matches" most of the time. It would have still failed with the
>> exactly same error if run in an empty repository, i.e.
>>
>> $ E=/var/tmp/x/empty && rm -fr "$E" && mkdir -p "$E" && cd "$E"
>> $ git init
>> $ rungit v2.6.6 submodule deinit .
>> error: pathspec '.' did not match any file(s) known to git.
>> Did you forget to 'git add'?
>> $ >file && git add file
>> $ rungit v2.6.6 submodule deinit .
>> $ echo $?
>> 0
>
> Allow no argument for `submodule deinit` to mean all submodules
> and add a test to check for the corner case of an empty repository.
>
> There is no need to update the documentation as it did not describe the
> special case '.' to remove all submodules.
OK, and the reason why there is no need to update the actual code,
other than the "do not allow" gate, is because "submodule--helper
list" aka module_list already knows to list everything if no
pathspec is given. Am I reading the code (not in the patch)
correctly?
> [1] http://news.gmane.org/gmane.comp.version-control.git/289535
The old discussion thread raises a good point. The refusal to
accept no-pathspec form for a potentially destructive "deinit" may
have been a safety measure, even though the suggested way to tell
the command "Yes, I know I want to deinit everything" was not a
good one (i.e. it resulted in an error if your project did not have
any files tracked yet).
So possible ways forward may be
- to remove the safety altogether; or
- keep the safety, but give a better suggestion to say "Yes, deinit
everything".
And this patch decides to take the former approach?
I am wondering if this can be solved in a cleaner way to teach
"deinit" take a new "--all" option instead, e.g. something like...
diff --git a/git-submodule.sh b/git-submodule.sh
index 82e95a9..4b84116 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -405,6 +405,7 @@ cmd_init()
cmd_deinit()
{
# parse $args after "submodule ... deinit".
+ deinit_all=
while test $# -ne 0
do
case "$1" in
@@ -414,6 +415,9 @@ cmd_deinit()
-q|--quiet)
GIT_QUIET=1
;;
+ -a|--all)
+ deinit_all=t
+ ;;
--)
shift
break
@@ -428,9 +432,9 @@ cmd_deinit()
shift
done
- if test $# = 0
+ if test $# = 0 && test -z "$deinit_all"
then
- die "$(eval_gettext "Use '.' if you really want to deinitialize all submodules")"
+ die "$(eval_gettext "Use '--all' if you really want to deinitialize all submodules")"
fi
git submodule--helper list --prefix "$wt_prefix" "$@" |
That would work even in the pathological "empty directory that has
nothing to match even '.'" case without losing the safety, no?
next prev parent reply other threads:[~2016-05-03 17:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-02 22:24 [PATCH 0/3] preparatory patches for the submodule groups Stefan Beller
2016-05-02 22:24 ` [PATCH 1/3] submodule deinit test: fix broken && chain in subshell Stefan Beller
2016-05-03 16:19 ` Junio C Hamano
2016-05-03 19:30 ` Stefan Beller
2016-05-02 22:24 ` [PATCH 2/3] submodule deinit: lose requirement for giving '.' Stefan Beller
2016-05-03 17:21 ` Junio C Hamano [this message]
2016-05-03 18:07 ` Stefan Beller
2016-05-03 19:08 ` Junio C Hamano
2016-05-03 19:22 ` Stefan Beller
2016-05-02 22:24 ` [PATCH 3/3] submodule init: redirect stdout to stderr Stefan Beller
2016-05-03 20:27 ` [PATCH 0/3] preparatory patches for the submodule groups Junio C Hamano
2016-05-03 20:53 ` Stefan Beller
2016-05-03 21:01 ` Junio C Hamano
2016-05-03 21:12 ` Stefan Beller
2016-05-03 21:32 ` Junio C Hamano
2016-05-03 21:57 ` Stefan Beller
2016-05-03 22:24 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqoa8nnjld.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=Jens.Lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=sbeller@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.