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

On 2009.02.15 15:53:50 -0800, david@lang.hm wrote:

On Sun, 15 Feb 2009, Junio C Hamano wrote:

quoted

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