Re: disallowing push to currently checked-out branch

> 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.