On Mon, Sep 10, 2007 at 03:44:16PM -0700, Junio C Hamano wrote: > Joel Becker <Joel.Becker@xxxxxxxxxx> writes: > > fact, when you are silently changing existing behavior, it's the people > > in between that will get bitten. The new user never knew the old way, > > and the git@vger reader already knows. > > For the record, I am with Joel on this one. That's why we ship > reasonably detailed Release Notes that mentions all the notable > changes in the release these days, starting from 1.5.0. We > probably could do more and/or better, but offhand I do not > think of a way to do so without being too verbose in the main > manual pages. We need to put it in the path of usage. Not everyone knows that git-core got upgrade (eg, the sysadmin did it), and even if they do (because they ran the update), who really takes the time to read the 100 changelogs of a "yum update"? This is why I call it "silently changed". So, the person comes across a behavior they didn't expect. The first thing they do is read the manpage. We need to have something there. Even if it's a tiny section near the bottom: BEHAVIOR CHANGE (see release notes) - 1.4 -> 1.5 Remote branch handling - 1.5.2 - > 1.5.3 Foo bar baz > Having said that, calling anything in the 1.5.0 release > "silently changed" _is_ going too far, I think. I think we made > a reasonable effort to make it clear certain things are > different, while the new tools would work on old repositories. How do you make it clear? "git-clone" did not print "hey, a new remote branch layout!" Release notes, by themselves, are unread when you "yum update" 100 packages. Let me be clear. The git documentation, overall, is really well done. The release notes are nice for someone who is asking "What has changed?". The problem is that Joe User doesn't *know* that something has changed. That's why I'm talking about the "path of usage". Get in front of Joe User the first place he checks for what he did wrong. He'll now know to check the release notes. > Certain packfile transfer features are only enabled after > software version negotiation on both ends, which unfortunately > would cause problems if you pull with 1.5.0 or later client and > still use older client in the same repository after that, but I > do not see much way around that without being too annoying to > the more typical users who use a single version of git on a > single repository (iow after upgrade, you do not mix, you keep > using the new one). People live in the real world. Machine 1 has a new version, machine 2 does not, and the working directory is on NFS. Silently corrupting is not a valid answer! If you change the repo such that $olderversion can't read it, force $olderversion to fail. You knew it ahead of time, you can force it. Your single-version-and-repo user will never have this problem. There's nothing to annoy them. Joel -- One look at the From: understanding has blossomed .procmailrc grows - Alexander Viro Joel Becker Principal Software Developer Oracle E-mail: joel.becker@xxxxxxxxxx Phone: (650) 506-8127 - 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
