Thread (27 messages) flat view 27 messages, 5 authors, 2016-06-15

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

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:46:13

Hi,

On Tue, 17 Feb 2009, Jay Soffian wrote:
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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help