On Sun, Feb 8, 2009 at 3:54 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
