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

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

From: Perry Wagle <hidden>
Date: 2016-06-15 22:45:15

On Aug 28, 2008, at 2:04 AM, Petr Baudis wrote:
 This thread is starting to seriously irritate even *me* by now, which
is quite a feat...

On Wed, Aug 27, 2008 at 05:05:33PM -0700, Perry Wagle wrote:
quoted
Oh yeah, sorry.  I neglected to mention that my problem was having  
the
git- forms in scripts all over an internal network, and having no
amazingly easy way of fixing them.  I don't know who all copied them.
 Should I count for you how many times the $PATH workaround has been
mentioned already? Or the gitexecdir workaround?
The PATH thing fixes the problem of typing in git-commands at the  
command line, but not for scripts containing git<DASH> commands.  I've  
seen no-one rebut my rebuttal.

Are you suggesting that I break into machines that I don't have access  
to add a export PATH= line to copies of scripts that were written 6  
months ago, and worked just fine until someone decided that "upward  
compatibility" wasn't an important concept?

What other upward compatibilities were broken in the past six months?   
What am I testing for tomorrow when I fix it before releasing an  
upgraded git?  Next month?

I really don't understand this "upward compatibility doesn't matter"  
thing.
 What the hell are you talking about? Did you *try*? git<SPACE><TAB>
does not do the same thing as git<DASH><TAB>, and it has been clearly
stated in this thread several times. It shows only the commands that  
are
*interesting* for the user, just as $PATH does not include /usr/sbin  
and
/sbin and /usr/lib/wine because the executables in these directories
just aren't interesting for the users. If you care about all the Git
internals, go read git(1) to see the list of all the plumbing stuff.
In this thread the new completion thing has been clearly stated both  
ways.

I have one, apparently very authoritative, response in this thread  
assuring me that it will not be the case that the command completion  
space will be restricted in the fashion you support.  I'm not sure who  
to believe.  It might not matter: apparently, one person in the thread  
was forced to make the change we are all responding to here.  When  
does that happen again?

I find the notion that the command completion should give partial  
results an unpleasant concept.  I've been stuck with systems with no  
documentation, but with command completion with that sort of thinking,  
and as a result, and it was very frustrating.

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