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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Aug 27, 2008, at 4:27 PM, Junio C Hamano wrote:

Steven Rostedt <rostedt@xxxxxxxxxxx> writes:

Yes, they are all a bunch of Nazi git fanatics, that Hitler himself would
have used the space version of git. He sent the Jews off to the
concentration camps because they insisted on using the dashes.

There, we have a Hitler reference.

CAN WE PLEASE LET THIS THREAD DIE!

Yeah, I second this.

The primary topic has already settled, and we will keep git-foo in libexec
even for built-ins.

This offtopic tangent that shouldn't even have started from the beginning must die now. It outlived its usefulness even as a place for people to
vent.

I suggested that git<DASH><TAB> used to give the same 143 completions that git<SPACE><TAB> would now. This meant that making any arguments that the number was off-putting to newbies did not apply, since you had a same number (143) either way. Putting stuff in libexec does not change the above observation in any fashion.

A response to my observation was that "not everything will show up in the latter completion". I balked at that as it distorted the truth. If this distortion would actually take place then I have a real complaint. Not a tangent.

But as long as git<DASH><TAB> does the *same* thing as git<SPACE><TAB>, I really do not see why you had to go break my scripts on a *minor* revision for what amounts to no reason as all.

Shells *hash* the PATH, so there is no "linear list" issue, and you have the *same* behavior for <TAB> completion both ways.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux