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

From: Jens Lehmann <jens.lehmann@web.de>
Date: Sep 23, 2012, 17:36 UTC
Message-ID: <505F489B.1000309@web.de>
In-Reply-To: <7v8vc13ilc.fsf@alter.siamese.dyndns.org>

Am 22.09.2012 22:31, schrieb Junio C Hamano:

Show 24 quoted lines

> Ramkumar Ramachandra <artagnon@gmail.com> 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.