Re: disallowing push to currently checked-out branch
- From
Jeff King <peff@peff.net>
- Date
- Feb 16, 2009, 22:52 UTC
- Message-ID
- <20090216225226.GB23764@sigill.intra.peff.net>
- In-Reply-To
- <76718490902161428k7d252a02i3e79e4f197608891@mail.gmail.com>
On Mon, Feb 16, 2009 at 05:28:38PM -0500, Jay Soffian wrote:
Show 10 quoted lines
> On Mon, Feb 16, 2009 at 4:15 PM, Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > >> 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:reposince 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