Re: disallowing push to currently checked-out branch

On Mon, Feb 16, 2009 at 5:52 PM, Jeff King [off-list ref] 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.