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

[Jeff King <peff@peff.net>]

On Thu, Aug 28, 2008 at 02:41:52PM -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)

Sorry, I thought you meant "the git community has put these bugs into
git" in the past 6 months. And I don't think that is true.

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

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

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

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

    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?

    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.

So

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

  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.

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

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

-Peff