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