Re: submodule: if $command was not matched, don't parse other args

Ramkumar Ramachandra [off-list ref] writes:

When we try to execute 'git submodule' with an invalid subcommand, we
get an error like the following:

    $ git submodule show
    error: pathspec 'show' did not match any file(s) known to git.
    Did you forget to 'git add'?

The cause of the problem: since $command is not matched, it is set to
"status", and "show" is treated as an argument to "status".  Change
this so that usage information is printed when an invalid subcommand
is tried.

Signed-off-by: Ramkumar Ramachandra <redacted>
---
 This breaks test 41 in t7400-submodule-bash -- does the test cover a
 real-world usecase?

You know how to ask "shortlog --since=18.months --no-merges" to find
people to list on "Cc:" line to ask that question, no?

I personally feel "no command means this default" is a mistake for
"git submodule", even if there is no pathspec or other arguments,
but I am not a heavy user of submodules, so others should discuss
this.

Am 22.09.2012 22:31, schrieb Junio C Hamano:

Ramkumar Ramachandra [off-list ref] writes:

quoted

diff --git a/git-submodule.sh b/git-submodule.sh
index a7e933e..dfec45d 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh

@@ -1108,7 +1108,15 @@ do
 done

 # No command word defaults to "status"
-test -n "$command" || command=status
+if test -z "$command"
+then
+    if test $# = 0
+    then
+	command=status
+    else
+	usage
+    fi
+fi

I personally feel "no command means this default" is a mistake for
"git submodule", even if there is no pathspec or other arguments,
but I am not a heavy user of submodules, so others should discuss
this.

The commit message of 97a5d8cce9 (git-submodule: re-enable 'status'
as the default subcommand) back from 2007 indicates that Lars did
back then think that "status" is a sane default. I agree with Junio
that this is not optimal, but I'd rather tend to not change that
behavior which has been there from day one for backward compatibility
reasons. But if many others see that as an improvement too I won't
object against changing it the way Ramkumar proposes (but he'd have
to change the documentation too ;-).

Since diff and status learned to display submodule status information
(except for a submodule being uninitialized) I almost never use this
option myself, so I'd be interested to hear what submodule users who
do use "git submodule [status]" frequently think.

On 12-09-23 01:36 PM, Jens Lehmann wrote:

Am 22.09.2012 22:31, schrieb Junio C Hamano:

quoted

Ramkumar Ramachandra [off-list ref] writes:

quoted

diff --git a/git-submodule.sh b/git-submodule.sh
index a7e933e..dfec45d 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh

@@ -1108,7 +1108,15 @@ do
 done

 # No command word defaults to "status"
-test -n "$command" || command=status
+if test -z "$command"
+then
+    if test $# = 0
+    then
+	command=status
+    else
+	usage
+    fi
+fi

I personally feel "no command means this default" is a mistake for
"git submodule", even if there is no pathspec or other arguments,
but I am not a heavy user of submodules, so others should discuss
this.

The commit message of 97a5d8cce9 (git-submodule: re-enable 'status'
as the default subcommand) back from 2007 indicates that Lars did
back then think that "status" is a sane default. I agree with Junio
that this is not optimal, but I'd rather tend to not change that
behavior which has been there from day one for backward compatibility
reasons. But if many others see that as an improvement too I won't
object against changing it the way Ramkumar proposes (but he'd have
to change the documentation too ;-).

Since diff and status learned to display submodule status information
(except for a submodule being uninitialized) I almost never use this
option myself, so I'd be interested to hear what submodule users who
do use "git submodule [status]" frequently think.

I also almost never use "git submodule [status]", and I also agree that
git-submodule shouldn't have a default sub-command.

(Honestly, submodule's status sub-command has always felt more like plumbing
to me than something a user would work with directly.  Maybe it's just the
full-length SHA's that put me off...)

		M.