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

From: Jay Soffian <jaysoffian@gmail.com>
Date: Jan 30, 2009, 18:50 UTC
Message-ID: <76718490901301050h1f0f5b2bq902de384d954d99b@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0901301756560.3586@pacific.mpi-cbg.de>

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.