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

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

On Aug 28, 2008, at 2:23 PM, Jeff King wrote:

> On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote:
>
>> But, my problem is not git<DASH> vs git<SPACE>, but the slap-dash way
>> upward compatibility was broken and the "water over the dam" slippery
>> slope rationalizations that refuse to consider reverting.  "You"  
>> will do
>> it again in the future since you are declaring success here.  And  
>> "you"
>> have likely done it in the past 6 months.
>
> I don't think Junio is declaring success. In fact, I think he has sent
> several messages saying (paraphrasing of course):

I did not name anyone, and put "you" in quotes to try to not even  
imply I was pointing at one person.  Several people have declared  
success, but Junio wasn't one of them.  I think (?) that he was just  
the unwilling gunman.  8)

> So please stop making specious claims that there are crazy
> backwards-incompatibility bugs lurking throughout new versions of git.
> If there are, then please find and name them. If not, then I think the
> git community would welcome suggestions about how better to notify  
> users
> about the rare changes like this one.

I now have to TEST to find those crazy backwards-incompatibility bugs  
before I can upgrade us to 1.6.0.  To test, I have to try to imagine  
what I and others were assuming about git.  And this episode means  
that I can't make any assumptions about the sanity of any changes  
since March, which is the version I'm thinking of upgrading.

But note that THIS upward compatibility bug has been declared to not  
be a bug.  Will any others receive the same stamp?

So please put on your engineer hat, and stop talking about "specious  
claims" and hurting feelings.  Heck, I even got Linus himself to ask  
if us people were on drugs, and I didn't take it personally.  At least  
I'm saying something that can be disputed, and not ad hominem like  
Linus.  8)

How to better notify them is to do it on a major release, like Git  
2.0.  THEN, they expect upward compatibility to break.

-- Perry