Re: disallowing push to currently checked-out branch

From: Jeff King <peff@peff.net>
Date: Feb 16, 2009, 05:06 UTC
Message-ID: <20090216050608.GA13181@coredump.intra.peff.net>
In-Reply-To: <alpine.DEB.1.10.0902152143430.14911@asgard.lang.hm>

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

Show 5 quoted lines

> two cycles of changes, not three, so 6-10 years for changes that break  
> existing bahavior without a _really_ pressing reason. so new functions,  
> new commands, new flags don't have to wait at all. it's only if you want  
> to change something that will cause grief for users if they get a new  
> version and run their existing tools against it.

I think you have to think about _how much_ grief it will cause, too.

Yes, some git enhancements are purely new functions and features that will not affect anyone who does not opt into them. But many enhancements cover cases that _must_ change behavior. Even bugfixes fall into this category. Who is to say somebody is not relying on the buggy behavior? So there must be some discretion for the maintainer to say "Anyone relying on this behavior is probably crazy".

And so there is some degree of cost-benefit. How much pain will this cause versus how much good will it do?

Show 6 quoted lines

> I am not interested in forking git. but I am saying that a backwards  
> incompatible change had better _really_ be worth it, and not just be worth 
> it for the people who live an breath git, but for the users as well (this  
> is a test that the dashed name elimination failed. in spite of a volcal  
> few saying that all the commands in the path were causing problems, most  
> people couldn't understand why the git people wanted to remove them)

Have you read the related threads in the archive? I think there is a significant sentiment that this change _is_ really worth it. The current behavior is hurting new users. I think the general consensus is that the default should change; the question is how and when.

The dashed-names change didn't go so well. You can argue whether or not it was a good change in the first place, but that is beside the point. The lesson to be learned there is that _how_ it was done could have been better. One of the things we are trying differently is having the warning. Another is that Junio is putting together a contact list for major projects using git. If you have a suggestion for another technique, I'm sure people will be open to it.

And as I said, I don't think a timetable has been set. But I would be surprised if it ends up in the 6-10 year range.

-Peff