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

From: Jens Lehmann <[email-masked]>
Date: Sun, 23 Sep 2012 19:36:27 +0200

Am 22.09.2012 22:31, schrieb Junio C Hamano:
> Ramkumar Ramachandra <[email-masked]> writes:
>> 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.