Thread (35 messages) flat view 35 messages, 13 authors, 2016-06-15

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

From: Jeff King <hidden>
Date: 2016-06-15 22:45:15

[dropping cc's because I think most people don't care about this bit]

On Thu, Aug 28, 2008 at 04:22:12PM -0700, Perry Wagle wrote:
What I saw was "git<DASH><SPACE> produces a list of 143 commands.  Long 
lists are inefficient.  Get rid of it!".  Actually the list is a hash 
table in any reasonable shell.  So its only aesthetics?
I saw some talk of efficiency, but it was mainly "100,000 files in one
directory makes your filesystem performance suck". But maybe somebody
talked about the shell. I think there is "143 is too many, and scares
new users". And I think there is "systems with hardlink problems ended
up with 100+ copies of the git binary, which is big". For the latter,
you could still keep git-* with a much smaller wrapper, of course.
Being able to quickly see the list is very useful.  That could be done  
with git<SPACE><TAB>, except some people want that to be lobotomized to 
show only a fraction of the total.  My mind boggles at that one.
I think there is a recognition that some of the commands aren't really
that useful to end users, but are kept around as helpers or as scripts.
For example, the interactive mode of "git add" is implemented in perl
(while the rest is implemented in C). So it is purely an implementation
issue that the script git-add--interactive exists. Nobody should be
calling it directly, but rather going through "git add -i", which will
call it as necessary with the right command line options.
But see my other post.  I'm over it.
Good. :)

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