Re: receive.denyCurrentBranch

[Jay Soffian <jaysoffian@gmail.com>]

On Sun, Feb 8, 2009 at 3:54 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> 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.