Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"

[Jay Soffian <jaysoffian@gmail.com>]

On Fri, Jan 30, 2009 at 12:01 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> As Peff commented, this would be horribly wrong if the remote has a
> different "origin" remote.  Not forcing the push does not help either, it
> is still wrong.

Got it. Here was my impression of the work-flow we're trying to help
beginners with:

machineA$ mkdir repo
machineA$ cd repo
machineA$ git init
machineA$ add, commit, add, commit...

machineB$ git clone ssh://machine1/repo
machineB$ add, commit, add, commit...
machineB$ git push

(And if my impression is wrong, then stop me right here and I'll
shut-up on this thread.)

In this case, the clone operation sets up the repo on B to fetch all
of the branches from the repo on A. But it doesn't do anything to help
the user with pushing the repo from B back to machine A. So perhaps:

git clone --origin machineA --push-as machineB ssh://machineA/repo

[remote "machineA"]
	url = ...
	fetch = +refs/heads/*:refs/remotes/machineA/*
	push = +refs/heads/*:refs/remotes/machineB/*

Now fetch and push are symmetric operations on machineB.

> But I think there is an even more fundamental problem: You do not want
> that default push.  We have "push only those refs the remote and the local
> repository share" rule for a reason.  It is way too easy to publish
> something you did not mean to publish otherwise.

I don't have a good answer for that, other than to say that if user is
setting up symmetric repositories, user wants to push everything.

j.