Re: disallowing push to currently checked-out branch

From: Jeff King <peff@peff.net>
Date: Feb 16, 2009, 04:05 UTC
Message-ID: <20090216040529.GC12689@coredump.intra.peff.net>
In-Reply-To: <alpine.DEB.1.10.0902152057500.14911@asgard.lang.hm>

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

Show 12 quoted lines

>> I'm not sure I understand your argument here. If you have a machine that
>> needs to do _exactly_ what you have tested, then wouldn't you be
>> concerned about upgrading git 1.5.6.5 to (for example) git 1.7? Or since
>> you are probably looking at a more macro-level, upgrading Debian 5.0 to
>> Debian 6.0?
>
> two points
>
> 1. someone running Debian 5 who then upgrades to Debian 6 should get the  
> warning, not the refusal, then when they go to Debian 7 the refusal can be 
> the standard (and substatute redhat enterprise version numbers for debian  
> if you want)

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

What about people who skip straight from 5 to 7? It's OK for them not to see the warning, because two major versions means they should read the release notes and re-test?

Show 5 quoted lines

> so a warning can go in at any time, but changing the default in a way  
> that's not backwards compatible needs to be done over a _very_ long  
> timeframe. so long that it's worth questioning if it's worth changing (as  
> opposed to either just leaving the warning, or trying to figure out a  
> different way)

There has been a lot of questioning, and a lot of discussion of alternatives already. Please check the list archive for some of it.

I don't think there is a timetable set at this point.

-Peff