Re: disallowing push to currently checked-out branch

On Sun, 15 Feb 2009, Jeff King wrote:

quoted

quoted

It is already implemented; the proposal is about setting the default.
The plans for 1.6.2 are already to issue a warning and ask the user to
set the config variable to shut it up.

if this is going to be done the timeframe for making the change should be

I don't know that a particular timeframe for switching the default has
been chosen at this point. There is a short warning in 1.6.1, and a much
more comprehensive warning will be in 1.6.2 (which should be released
shortly).

quoted

quite long. think in terms of debian stable or RHEL, whatever version they
ship is what their users are going to use. it doesn't matter how many new
versions and what warnings you have the produce in the meantime, the users
won't see them.

Sadly, Debian 5.0 just shipped with git 1.5.6.5, which has no warning
(and dashed commands!).

quoted

note that this isn't always stupid to do, if you are deploying them on a
network with no Internet access the stability of knowing that things are
_exactly_ what you tested may be worth more than updates that close bugs
that you don't hit or add features that you aren't using (or introduce
unexpected changes like spitting warnings or errors for things that the
old version didn't, which is exactly what is being proposed.

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)

2. you can't count on users upgrading any faster than I tak about in 
#1. Debian shipped 1.5.6.5 in 5.0, when users upgrade to Debian 6.0, you 
can't assume that they _ever_ patched the system, so even if you released 
a 1.5.6.6 today that had the warning in it, you can't assume that users 
saw it and so it's safe to remove the dashed commands in the version that 
will ship with Debian 6.0.

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)

David Lang