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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Fri, 30 Jan 2009, Jay Soffian wrote:

> On Thu, Jan 29, 2009 at 7:34 PM, Johannes Schindelin
> <johannes.schindelin@gmx.de> wrote:
> > Many, many users set up non-bare repositories on their server, and are 
> > confused that the working directory is not updated.
> 
> This comes up on the list from time-to-time and is even in the FAQ.

So much so that it is high time we admitted that we have a design bug 
there.

> It has even been suggested that HEAD be detached when pushing into a 
> non-bare repository, but I am not suggesting that again.

No, because that would be as wrong as trying to update the working 
directory in any other way.  (Not only is it possible that you are a 
git-shell user, in which case you have no business meddling with the 
working directory -- or the symbolic ref HEAD -- to begin with, but you 
also run into the problem that you might not know where the working 
directory is at all, let alone if there is one.)

So it is a good thing you are not suggesting it again.

> I wonder if it might be helpful to teach clone to setup a push line in
> the cloned repo. i.e.:
> 
> [remote "origin"]
> 	url = ...
> 	fetch = +refs/heads/*:refs/remotes/origin/*
> 	push = refs/heads/*:refs/remotes/origin/*
> 
> This could be a configurable default behavior when cloning from a
> non-bare repo (can that be determined?) and/or as a switch
> (--satellite perhaps?).

As Peff commented, this would be horribly wrong if the remote has a 
different "origin" remote.  Not forcing the push does not help either, it 
is still wrong.

But I think there is an even more fundamental problem: You do not want 
that default push.  We have "push only those refs the remote and the local 
repository share" rule for a reason.  It is way too easy to publish 
something you did not mean to publish otherwise.

Ciao,
Dscho