PUSH_HEAD, was Re: disallowing push to currently checked-out branch

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 17, 2009, 11:28 UTC
Message-ID: <alpine.DEB.1.00.0902171200250.6185@intel-tinevez-2-302>
In-Reply-To: <76718490902162153m6a524b2dv335be66a0f0294ca@mail.gmail.com>

Hi,

On Tue, 17 Feb 2009, Jay Soffian wrote:

Show 5 quoted lines

> My head is playing around with two ideas now that Dscho has mentioned:
> 
> receive.localBranches = (refuse | allow)
> 
> http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78065

In the meantime, we have receive.denyCurrentBranch, which is much superior to the localBranches design: it tackles the _real_ issue -- the only reason why a current branch cannot be updated lightly is that it might have a working directory which would be forced out-of-sync.

Show 6 quoted lines

> And PUSH_HEAD.
> 
> The idea would be for side-pushes never to update a local branch, but to 
> be recorded in PUSH_HEAD. You'd be able to rebase/merge local branch 
> on-top of changes in PUSH_HEAD. I'm trying to figure out what can make 
> sense when pulling from such a repo.

Sorry, I should clarify what I mean by PUSH_HEAD:

The idea is to have the _same_ as FETCH_HEAD, i.e. a simple file (.git/FETCH_HEAD) listing all the branch tips that have been pushed, _no matter_ if they were successfully stored as refs.

Just do this in a repository which is lagging behind origin a little:

	$ git fetch origin

and then see that a file .git/FETCH_HEAD exists. As long as you are only interested in the first rev, you can even use "FETCH_HEAD" as a rev name:

	$ git show FETCH_HEAD

The important feature of this method is that FETCH_HEAD is not fetchable. Neither 'ls-remote' nor 'branch' will show it.

BTW a PUSH_HEAD could also help the issue that when updating of a ref was refused, all the objects will have to be transferred via the wire again when pushing somewhere else.

Having said all that, I can easily live without PUSH_HEAD.

Ciao, Dscho