Re: [RFC - draft] List of proposed future changes that are backward incompatible

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2009.02.15 15:53:50 -0800, david@lang.hm wrote:
> On Sun, 15 Feb 2009, Junio C Hamano wrote:
>
>> Thanks.
>>
>> * 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 I understand this one, it will cause grief for quite a few people.
>
> I have a public repository that I push to and then have a trigger that  
> checks out the current version, compiles it, publishes the compiled  
> version, sends an announcement, etc
>
> if I am understanding the purpose of this change, you would prohibit the  
> update from taking place.

In the "non-bare" FAQ entry, there's a link to a post-update hook that
tries to resolve pushes to the branch head referenced by HEAD, and
at least on #git, there were people that preferred using that hook
instead of setting up a bare repo. So you're probably not the only one
with such a setup.

How about having the default in the code being a warning, but the
default for new repos being "reject"? IOW, set receive.denyCurrentBranch
accordingly in the .git/config file for new non-bare repos? That way,
for your existing repos, you get a warning with instruction that you can
set a config entry to kill the warning or to forbid the potentially
destructive operation. So it's just a new warning, and your existing
setups don't break.

But for new repos, you get the rejection behaviour and have to change
the config if you really want to push to the current branch, along with
setting up the hook and whatever else you need, so it's just one more
step you need to take now.

Björn