On Mon, Feb 16, 2009 at 05:28:38PM -0500, Jay Soffian wrote:
> On Mon, Feb 16, 2009 at 4:15 PM, Johannes Schindelin
> <Johannes.Schindelin@xxxxxx> 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: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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
