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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
