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 15:24:41 -0700 [thread overview]
Message-ID: <xmqq7ffalqza.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAGZ79kZK_EtwBps3hcYVkRat2XbpXXXdXkQDrB281rxkedjaGA@mail.gmail.com> (Stefan Beller's message of "Tue, 3 May 2016 14:57:00 -0700")
Stefan Beller <sbeller@google.com> writes:
>> I wouldn't be surprised if many people wished that "git branch" did
>> not list (and required "git branch -l" to list) to scroll everything
>> they are looking away but instead showed what the current branch is.
>
> Isn't that yet another more specialized mode of operation?
Yes. It all boils down to "what is the most common thing people
would want" and "which one of these operation modes deserve the
short-hand".
Most often, the first one that gets invented ends up squatting on
the short-and-sweet "by default without parameter, we do this" slot,
and we have to let it squat forever due to backward compatibility.
I think "git branch" that shows all 300 branches is a good example
of that--if we didn't have command line prompt support, I am
reasonably sure that "git branch --current-branch" would have been
added by popular request long time ago, and that would be a more
common thing people would want than "git branch -l". I would not be
surprised if in an alternative universe in which both "list" and
"tell me current" were available back when the "no option default"
had not been defined yet, we gave the shortest-and-sweetest to "git
branch ---current-branch".
prev parent reply other threads:[~2016-05-03 22:25 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
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 [this message]
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=xmqq7ffalqza.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.