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