Re: receive.denyCurrentBranch

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 9, 2009, 11:06 UTC
Message-ID: <alpine.DEB.1.00.0902091204100.10279@pacific.mpi-cbg.de>
In-Reply-To: <20090209050659.GA12655@mini-me.lan>

Hi,

On Mon, 9 Feb 2009, Theodore Tso wrote:

Show 19 quoted lines

> On Sun, Feb 08, 2009 at 08:47:26PM -0500, Jay Soffian wrote:
> > I agree that a detached HEAD is a bad idea. The closest parallel that
> > I can come up with for git would be for receive-pack to store incoming
> > changes into separate branch hierarchy, NOT for it to detach HEAD. A
> > toy-patch I played around with earlier allowed this on the non-bare
> > upstream repo:
> > 
> > [receive]
> >      prefix = refs/remotes/incoming
> > 
> > Then a push to refs/heads/master was automatically stored as
> > refs/remotes/incoming/master instead.
> 
> What happens when the next person pushes to the same remote repo, and
> their refs/heads/master push is not a fast-forward merge of the
> current refs/remotes/incoming/master?
> 
> Do you lose the first user's push at that point?  Or do you refuse the
> push?

This is meant for non-bare repositories, right? Repositories that do have reflogs...

Ciao, Dscho

P.S.: There _have_ been times when I would have liked an automatic PUSH_HEAD that is always temporary, such as FETCH_HEAD. I _could_ imagine that this is something we could do (opt-in, of course): storing what was already pushed in a PUSH_HEAD, even if the refs could not be updated.