Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"

From: Sam Vilain <sam@vilain.net>
Date: Feb 2, 2009, 10:50 UTC
Message-ID: <1233571805.20131.358.camel@maia.lan>
In-Reply-To: <7v1vuhkzmp.fsf@gitster.siamese.dyndns.org>

On Mon, 2009-02-02 at 00:32 -0800, Junio C Hamano wrote:

Show 20 quoted lines

> > The other affects
> > a small number of users who are doing something which is labeled in many
> > places as a bad thing to want to do.
> 
> Sorry, but I do not agree with this.
> 
> What is bad is to push into a repository that is used for editing.  That
> is labelled as a bad thing to want to do.
> 
> It is often the easiest to push and then run "reset --hard" (perhaps from
> the post-update script) to propagate your change to a repository that is
> not usually used for editing.  E.g. that has always been the way I update
> my private repository at k.org that I use for final testing before pushing
> out the results that I built and tested on my personal machine.  People
> who have live web pages served from a checkout do that, too.  It is not a
> bad thing to do at all, and you can find many instructions with google
> without spending a lot of time to do exactly that.
> 
>     http://kerneltrap.org/mailarchive/git/2008/7/1/2315924
>     http://utsl.gen.nz/git/post-update

Heh, thanks for referring me to my own script ;-)

I think a "repository that is used for editing" can be practically defined as one which does not have any dirty local files. Or, if there are dirty local files then they are none of the files which would be changed by the push, or none of them would be changed by the push. Similar to the check that 'git merge' does.

With that definition, if receive.denyCurrentBranch is set to "update" it could be pretty much automagic, perhaps even good enough behaviour to consider making it the default. This kind of behaviour is what my post-update hook tries to achieve, but it really needs a corresponding piece in the update hook, and I didn't code all of the conditions above into it.

Sam.