Re: disallowing push to currently checked-out branch

[Jay Soffian <jaysoffian@gmail.com>]

On Mon, Feb 16, 2009 at 5:52 PM, Jeff King <peff@peff.net> wrote:
> Actually, I think it is pulling from the non-bare repo that will get
> confusing.
>
> You are proposing to push, when pushing into a non-bare repo, into a
> push refspec like refs/incoming/ (for example). But what is your fetch
> refspec?
>
> If it fetches as usual from refs/heads/, then you have an asymmetry.
> That is, if I do "git push" on one client, then "git pull" on another
> won't fetch the changes. I have to wait for the non-bare repo to pull
> them into its refs/heads/ hierarchy (one by one, if there are multiple
> branches).
>
> So you can try putting refs/incoming into your fetch refspec if it is a
> non-bare repo. But there are two issues there:
>
>  - how do you know the remote is non-bare?
>
>  - now you have to "push" in the non-bare upstream in order to make
>    commits available. So it no longer works to do:
>
>       workstation$ cd repo && hack hack hack && commit commit commit
>       laptop$ git clone workstation:repo
>
>    since you will silently end up with stale results.
>
>    In some ways, this is nicely rigorous: non-bare repos become
>    essentially "uncontactable" remotely, and you have a de facto bare
>    repo in the form of refs/incoming sitting in between. But I'm not
>    sure it matches what most users want to do, and certainly it causes
>    more breakage to their workflows than receive.denyCurrentBranch.

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

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.

j.