Re: receive.denyCurrentBranch

From: Jay Soffian <jaysoffian@gmail.com>
Date: Feb 8, 2009, 22:51 UTC
Message-ID: <76718490902081451xd953e84y33de64cc82c1da42@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0902082149380.10279@pacific.mpi-cbg.de>

On Sun, Feb 8, 2009 at 3:54 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 7 quoted lines

> Just to make it clear: if you have merge conflicts on the remote end, you
> will get into trouble.
>
> I do not know how Mercurial handles this (I am sure you will send a
> page-long mail illustrating it), but in my humble opinion, there is _no_
> way to handle this except if you have shell access to the remote
> repository/working directory.

I apologize for my prior reply. I understand you find any mention of Mercurial offensive. But if you had paid attention, you would have noticed that Mercurial did not attempt to merge. Rather, it created a new branch head in the remote repository.

The equivalent in git would be for the user to do something like this:

satellite:~/repo (master)$ git push origin
! [remote rejected] master -> master (branch is currently checked out)
satellite:~/repo (master)$ git push origin master:satellite-master
 * [new branch]      master -> satellite-master
satellite:~/repo (master)$ ssh origin
origin$ cd repo
origin:~/repo (master)$ git merge satellite-master

> No matter if you suggest leaving merge conflict, a detached HEAD, or
> "read-tree -u -m HEAD" (i.e. trying a simple merge with the working
> directory): _all_ of them are unsafe.

I'm not suggesting any of those things. I was just illustrating what another DVCS does to see if there was anything that might be learned from it.

Clearly users are confused about pushing into a checked-out branch. Maybe making that impossible by default will be enough.

j.