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

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

 



On 12-09-23 01:36 PM, Jens Lehmann wrote:
> 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.

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.

--
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]