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

[Jeff King <peff@peff.net>]

On Thu, Aug 28, 2008 at 03:33:26PM -0700, Perry Wagle wrote:

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

No, it really is the first time.

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

Yes, and some of the test scripts still have git-* in them. I think in
that respect, the git community has been very bad about eating our own
dog food.

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

I think the bug is not in the change, but in the deprecation process and
communication. But I think the definition of "bug" is vague enough to
simply be in the eye of the beholder.

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

Ultimately you must be the judge of what and how much to test on your
systems. But if you are asking if there are other similar compatibility
bugs in 1.6.0, then my opinion, as somebody who follows the git list
quite closely and contributes some code, is that no, there are not.

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

Induction in this manner is not a very rigorous argument (we're being
engineers, right?). I gave several reasons already why the probability
is low that another such bug exists, mostly related to the lack of
indicators.

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

Sure, I wouldn't want to go back and read all of the messages either.
But this was mentioned in the release notes, too. Why don't you start
with them?

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

That isn't quite what I meant. What I meant was that our idea of a major
version number is the middle number. That is, the time to introduce a
few minor incompatibilities is when that number jumps (but they should
be documented for a significant time period ahead of time, which this
was).  I don't expect to jump to "git 2.0" basically ever. Just as I
don't really expect Linux 3.0 anytime soon. But I, of course, am not in
charge of such things, so you may take that with a grain of salt.

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

I think the reasons have been mentioned a few times. Maybe you just
didn't think they were good.

-Peff