Thread (76 messages) flat view 76 messages, 33 authors, 2016-06-15

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

From: Willy Tarreau <w@1wt.eu>
Date: 2016-06-15 22:45:14

Possibly related (same subject, not in this thread)

On Tue, Aug 26, 2008 at 01:16:24PM -0400, Jeff King wrote:
On Tue, Aug 26, 2008 at 10:12:55AM -0700, Shawn O. Pearce wrote:
quoted
I'm the reason why count-objects, ls-tree and checkout-index are
still offered by the bash completion.  And sitting here reading your
email I realized its been _months_ since I last called checkout-index
by hand.  I still run count-objects and ls-tree very so often, but the
average user probably doesn't use ls-tree.

So yea, these probably should be removed from the completion list.
But I can make a weak argument for keeping count-objects.
I think this message shows the conflict in setting up such a list. We
want the command set to be as tiny as possible to help new users find
their way. But we want the command set to be useful to git power users.

I wonder if there should be multiple sets of commands for completion,
with a minimal set enabled by default, and a "power user" set that
exposes extra commands. I dunno. Maybe that is overengineering. I don't
even use the bash completion at all.
The problem is not caused by the number of commands, but by their
complexity. I need completion because it's hard to type their very
long names without making mistakes (not counting the long options).
"git am" is fine with me, but "git format-patch" is quite boring to
type. It's also interesting to note that short names are currently
in place for less commonly used commands : git-rm, git-mv, git-gc.

Willy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help