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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 22.09.2012 22:31, schrieb Junio C Hamano:
> Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]