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

[Marc Branchaud <mbranchaud@xiplink.com>]

On 12-09-23 01:36 PM, Jens Lehmann wrote:
> Am 22.09.2012 22:31, schrieb Junio C Hamano:
>> 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.

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.