Re: disallowing push to currently checked-out branch

On Mon, Feb 16, 2009 at 05:28:38PM -0500, Jay Soffian wrote:

On Mon, Feb 16, 2009 at 4:15 PM, Johannes Schindelin
[off-list ref] wrote:

quoted

quoted

Not consistent with what?

With pushing into bare repositories.  And worse, with the existing mode of
operation.

I don't understand why pushing into a bare repo should have the same
behavior as pushing into a non-bare repo. They are different workflows
after-all.

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.

-Peff