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

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

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

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

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

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