Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From
- Perry Wagle <wagle@cs.indiana.edu>
- Date
- Aug 28, 2008, 22:33 UTC
- Message-ID
- <3DE083DB-ADFF-45E7-B3EB-A76985941271@cs.indiana.edu>
- In-Reply-To
- <20080828215907.GE27867@coredump.intra.peff.net>
On Aug 28, 2008, at 2:59 PM, Jeff King wrote:
Show 18 quoted lines
>> 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?
Show 7 quoted lines
> - 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.
Show 5 quoted lines
> 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.
Show 6 quoted lines
> 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.
Show 5 quoted lines
> 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.
Show 7 quoted lines
>> 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.
Show 14 quoted lines
>> 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