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

[Perry Wagle <wagle@cs.indiana.edu>]

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:
>> 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