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

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.

quoted

   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.

quoted

 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