Re: [PATCH 0/3] preparatory patches for the submodule groups

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

 



On Tue, May 3, 2016 at 1:27 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> writes:
>
>> Stefan Beller (3):
>>   submodule deinit test: fix broken && chain in subshell
>>   submodule deinit: lose requirement for giving '.'
>>   submodule init: redirect stdout to stderr
>
> So...
>
>  * I'll take "&&-chain" patch on a separate topic on 84ba959, to be
>    later merged to 'master' and probably to 'maint'.
>
>  * I'll queue the "send diag message to stderr" patch on top of
>    sb/submodule-init.
>
>  * As to the second one, I prefer to hear opinions from others
>    before choosing the possible two approaches.  Perhaps losing the
>    "safety" is acceptable.  Otherwise, we could use the one I sent
>    but with a "-a and pathspec are incompatible" fix.  That can be
>    on its own separate topic.

I have your patch here and have a "-a and pathspec are incompatible" fix
build on top.
* I do wonder if we want to have the shortform '-a' though.
* I think we want to head for consistency, eventually.
   e.g. commands with no arguments such as tag, branch
   give a list of their respective domain.

   Subcommands do not give lists by default, e.g.
   `git stash clear`, `git remote prune`
   which are the moral equivalent to
   `git submodule deinit` just work as they were told, no --switch needed.
   However Jonathan suggests we may want to reserve the no arguments space
   for future use and use the '--all' instead.
--
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]