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

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

quoted

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.

My engineer hat _is_ on. Here is the logic that led to my use of the
phrase "specious claims":

Cool.  Thanks!  (seriously)

 - you are claiming that there are backwards incompatibility changes
   lurking in git (or at least that is what I believe you to mean)

I'm saying that I don't know and will have to do complete exhaustive  
testing to be sure (my faith in git has been severely shaken).  I  
already tested every step for months, and to do it "right", I have to  
do that all over again.  I don't have the time, so I have to do severe  
approximations.  One of the fixes is to see if I can get people to  
stop making frivolous changes: "ooo!  we have to rename everything in  
the API because lists, I mean hashtables, with 143 entries in them are  
offensive!".  If there was more reasoning than that, it was not  
displayed in this thread.

 - there has been _one_ such problem, and the person responsible for
   vetting such changes has solicited suggestions for doing better in
   the future. I don't think that is indicative of a pattern of such
   changes.

Ok.  My suggestion is that it shouldn't have been done in the first  
place, and we should now revert.  But others are saying over and over  
"its done!  live with it!".  I came in late.  What did I miss in the  
last 6 months.  Sounds like people have lots of practice with these  
water-over-the-dam's, surely this isn't the first time?

 - But let's say you have lost some faith in the git development
   process due to _this_ bug. But let's look at the history of this
   bug. It has been discussed several times for the past 2 years,  
along
   with a mention in the release notes several versions ago. It was  
not
   a surprise to anybody who has been developing git.

In March 2008, the sample git-hooks and git-web used git<DASH>  
commands.  That was the last I looked at git until Tuesday of this week.

   So yes, maybe there _are_ other bugs just like it lurking. But
   wouldn't it stand to reason that those bugs have _also_ been
   discussed and mentioned in the release notes, or that the  
developers
   would know about them?

This is declared to not be a bug, even though it breaks existing  
scripts, even those published in the main branch of git itself.

   In other words, I can see you losing enough faith to say "wow, the
   git developers don't communicate very well and I need to vet their
   changes and notes more carefully". I don't think it is reasonable  
to
   say that there are likely to be other, totally unknown backwards
   incompatible changes.

I'm going by the reasoning shown in this thread.  Why not?  I'm  
looking for a way not to have to do exhaustive testing on those  
scripts, so would love to hear it.

So

 1. I find your claim that such bugs exist to have little evidence to
    back it up.

Induction.  If it happened once, it probably happened more than once.   
This wasn't a show stopper problem.  It wasn't broke, but it was  
"fixed" anyway.

 2. As an engineer, I have seen evidence of one problem (insufficient
    communication) but not of another (introduction of
    incompatibilities without on-list discussion). So I would choose  
to
    focus my resources on fixing the problem I have seen.

I don't know what I missed, and am not sure how to search for in in  
ten thousand messages or so since March.  My style is to anticipate  
problems.

But I'll figure it out.  Part of that figure out process is posting to  
this thread.

quoted

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)

Sorry, but I'm not impressed by your getting Linus to yell at you.  
It's
like shooting fish in a barrel. :)

Yeah, well, that was supposed to be both a joke and to indicate that  
I'm not sitting here with steam coming out my ears.

Linus has his solution, that doesn't work for me.  He hasn't listened  
to my several attempts to say why, and he's mad because he thinks I'm  
not listening.  But I expect he's a busy guy with 10,000 emails a day  
to respond to, so them's the breaks.

quoted

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

Now that _is_ a reasonable suggestion. This change _did_ wait until  
the
jump to 1.6.0, which we thought of as a major version jump (just as  
1.4
to 1.5 introduced a few minor but documented changes). I don't think
there is a plan for "git 2.0" short of serious incompatibilities in  
the
repo format (i.e., you can't use 2.x tools on 1.x repos and vice  
versa).
So perhaps our numbering should be more emphatic.

I think I hear you.  Since git is young, I should expect  
incompatibilities with minor version changes, and not demand that they  
be held off for major version changes.  That seems very plausible.

But I think I'll still remain wary because 1.6 introduced a nearly  
complete renaming of the API for what, in this thread anyway,  
completely silly reasons.  If there are good reasons, I haven't seen  
them.

-- Perry