From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: Jens Lehmann <Jens.Lehmann@web.de>,
"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 0/3] preparatory patches for the submodule groups
Date: Tue, 03 May 2016 14:01:47 -0700 [thread overview]
Message-ID: <xmqqoa8mlutg.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAGZ79kakayOhPkCK4hbRkj-h2Bt+PqD69EgHk-chbu4xCA8_pA@mail.gmail.com> (Stefan Beller's message of "Tue, 3 May 2016 13:53:30 -0700")
Stefan Beller <sbeller@google.com> writes:
> 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 do not particularly care. I was merely matching the other two
options there.
> * 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.
Isn't that a historical mistake we are regretting, though? Only
after many other operation modes were invented and "create X" proves
not to be the only primary modes we had to invent "tag -l" and
"branch -l". Aren't we better off not having "no option means list"
kind of default?
> 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.
I wouldn't say "git rm" should remove everything by extending that
logic, but I can certainly buy if somebody argues "git submodule
deinit" is not destructive enough to warrant extra safety.
next prev parent reply other threads:[~2016-05-03 21:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-02 22:24 [PATCH 0/3] preparatory patches for the submodule groups Stefan Beller
2016-05-02 22:24 ` [PATCH 1/3] submodule deinit test: fix broken && chain in subshell Stefan Beller
2016-05-03 16:19 ` Junio C Hamano
2016-05-03 19:30 ` Stefan Beller
2016-05-02 22:24 ` [PATCH 2/3] submodule deinit: lose requirement for giving '.' Stefan Beller
2016-05-03 17:21 ` Junio C Hamano
2016-05-03 18:07 ` Stefan Beller
2016-05-03 19:08 ` Junio C Hamano
2016-05-03 19:22 ` Stefan Beller
2016-05-02 22:24 ` [PATCH 3/3] submodule init: redirect stdout to stderr Stefan Beller
2016-05-03 20:27 ` [PATCH 0/3] preparatory patches for the submodule groups Junio C Hamano
2016-05-03 20:53 ` Stefan Beller
2016-05-03 21:01 ` Junio C Hamano [this message]
2016-05-03 21:12 ` Stefan Beller
2016-05-03 21:32 ` Junio C Hamano
2016-05-03 21:57 ` Stefan Beller
2016-05-03 22:24 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqoa8mlutg.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=Jens.Lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.