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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 30, 2009, 19:03 UTC
Message-ID: <alpine.DEB.1.00.0901301959300.3586@pacific.mpi-cbg.de>
In-Reply-To: <76718490901301050h1f0f5b2bq902de384d954d99b@mail.gmail.com>

Hi,

On Fri, 30 Jan 2009, Jay Soffian wrote:

Show 20 quoted lines

> 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.)

I think your impression is not wrong.

BUT.

You cannot just cater for one workflow and fsck the other workflows over.

You'll have to devise a method that helps the workflow you are interested in, but leaves the others alone.

Example: the thing I heard most often was "I want to start this 
repository, but there is nothing in there yet, yet I want other people to 
clone it already so they'll see something when I do."

I admit, it does not strike me sensible, but so does cloning an empty repository. As I could not understand how people would want to vote for Bush. Yet they did, so I guess I'll have to live with it.

Ciao, Dscho