Re: disallowing push to currently checked-out branch

On Sun, Feb 15, 2009 at 09:18:47PM -0800, david@lang.hm wrote:

quoted

So people doing major version upgrades of their OS don't need to read
release notes or re-test behavior?

when was the last time you read the release notes for an entire distro?

Since you ask, I track Debian unstable and I read the release notes
(NEWS.Debian) for every package that I upgrade, and skim the changelogs
for perhaps half.

But yes, I realize that is not common; I don't expect that every user
reads every release note.

My point is that things _are_ going to change in a major version OS
upgrade. It is up to the user to make the tradeoff of how much time they
want to spend researching those changes versus the likelihood and
severity of breakage. If I have a mission critical system running git,
I'm going to read git's release notes. If I don't, then I will probably
accept that something could break, and fix it if it does.

and it's not a matter of reading the release notes. it's a matter of them  
running a version that gives them a warning before you feed them a version 
that will cause their existing stuff to fail.

The warning is not a panacea:

  1. It might actually cause breakage. Less likely than a straight
     change in behavior, but still possible.

  2. Users don't necessarily see the warning. By definition, it is not
     changing the behavior. So unless they are examining the output
     (which might not be the case for an unattended system), it can go
     unnoticed.

So all of the problems you are talking about are still possible even
with an extremely long change cycle.

I recognise that not all software is concerned about backwards  
compatibility, but if git wasn't concerned with backwards compatibility  
and a graceful upgrade process, this thread wouldn't exist.

I think git is much better about backwards compatibility than most
packages I have seen. But there is a cost to maintaining it completely
and forever, in that you are either hampered in what you can do (i.e.,
there are enhancements you would like to make but can't) or you pay an
awful burden in development cost maintaining two diverging codebases.

Based on the numbers in your last email, you seem to be advocating a
9-15 year lag on making any behavior changes in git. I'm sorry, but I
have no interest in waiting that long to see enhancements I work on in
git make it into a released version.

I think Junio is doing a fine job at dealing with backwards
compatibility and keeping things moving at a reasonable pace. If you
think it should go slower, you are certainly welcome to fork and release
an "ultra-stable" version of git that reverts any backwards incompatible
changes while keeping up with other new features.

-Peff