Re: disallowing push to currently checked-out branch

From: david@lang.hm <david@lang.hm>
Date: Feb 16, 2009, 01:33 UTC
Message-ID: <alpine.DEB.1.10.0902151727330.14911@asgard.lang.hm>
In-Reply-To: <20090216000443.GB3503@coredump.intra.peff.net>

On Sun, 15 Feb 2009, Jeff King wrote:

Show 18 quoted lines

> On Mon, Feb 16, 2009 at 01:20:13AM +0200, Heikki Orsila wrote:
>
>>> * git-push to update the checked out branch will be refused by default
>>>
>>>   Make "git push" into a repository to update the branch that is checked
>>>   out fail by default.
>>>
>>>   http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
>>
>> If this is implemented, it shouldn't, in my opinion, be a default
>> setting. I regularly push to checkout repos when I'm doing cross machine
>> development. However, I could live with a configurable setting as
>> proposed in the given URL. I think Git should not be too cautious about
>> following users instructions. The user knows what is best for him/her ;)
>
> 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 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.

to the progression needs to be

one upgrade cycle the user is using the old version with no warning.

next upgrade cycle the user is using a version with a warning.

the third upgrade cycle the user is using the version with the default changed.

the problem is that these upgrade cycles are 3-5 years each, and it's not unusual for the types of users that use dbian stable or RHEL to be running these systems in places where they do not get patched during their lifetime.

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.

David Lang