On Fri, May 4, 2012 at 10:27 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > >> On Thu, May 3, 2012 at 9:13 PM, Rich Pixley <rich.pixley@xxxxxxxx> wrote: >> ... >>> $ # ...do some work... >>> $ hg push # assume this collides >> >> % git push >> >>> pushing to $uri_for_cache_repo >>> searching for changes >>> abort: push creates new remote head 6d2eb0a6a278! >>> (you should pull and merge or use push -f to force) >>> $ hg push -f # the pull and merge case parallels git, so let's use push -f. >> >> This is stupid, why make everybody else's life difficult? Let's merge here. > > Doing "hg push -f" _regularly_ is probably stupid, but you need to step > back a bit. There is a valid situation where you may sometimes want to > publish unmerged work for others to see. > > The person who is trying to push here may be quite junior, and may not be > yet familiar with the areas of the project outside what he has worked on. > In his attempt to "pull and then push", he can end up having to resolve a > merge conflict that he is not capable of handling correctly. Regardless of > the VCS used, you would want to give a way to this junior developer to ask > for help "here is my work; while I was working on it, the baseline has > been diverged greatly and I need help either merging it or rebasing it." Sure, but is 'push -f' the right solution? If a junior really has no idea about what he is doing, I wouldn't want him pushing another 'head' to the master branch. Can mercurial really do a rebase only on a specific head of a branch? Even if mercurial can do that, the result can be quite messy; one guy doing a rebase, another guy doing a merge, another guy doing a different merge, another a different rebase; if they know what they are doing, they will avoid 'push -f' and revert or rebase their changes when they notice somebody else tried to do something similar, but maybe one of them is a slightly more advanced junior and actually does 'push -f', and we go into yet another round of conflict resolving. It doesn't matter how you look at it; 'push -f' is not ideal. In the git world there's many ways to resolve this; push to another branch, push to another repo, allow ssh access to your machine, send the changes by mail, copy the git repo to a shared location, etc. *All* of those alternatives are better than 'push -f'. It seems to me that this *huge* thread basically boils down to Rich wanting 'hg push -f', when clearly that just creates problems, even in mercurial. Cheers. -- Felipe Contreras -- 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