Re: Newbie grief

From: Junio C Hamano <gitster@pobox.com>
Date: May 4, 2012, 20:27 UTC
Message-ID: <7v4nrvadzq.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAMP44s2w9B0Jvcn44R5_-ptC=x+5=OgGF0n0SkH+t0JjomXsGA@mail.gmail.com>

Felipe Contreras <felipe.contreras@gmail.com> writes:

Show 14 quoted lines

> On Thu, May 3, 2012 at 9:13 PM, Rich Pixley <rich.pixley@palm.com> 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."

In that context, I can see that Hg's split head could be _one_ way to implement it. You just push and force split the head at the remote, leaving others to sort out the resulting mess.

But that is not necessarily the _only_ way to implement it. A Git user would probably push his work to either his own public repository, or in an environment like Rich illustrated, to refs/remotes/junior/need_help_xyzzy of the central repository of the organization, and ask other people to help him. And when he does so, he needs to tell them where they can find his work, either the url to his own repository (and its branch), or his branch at the shared place, and that is where the naming of branch becomes meaningful. Instead of saying "There is 6d2eb0a6a278 in the repo that I need somebody to help merging", the request-for-help message can say "I placed my WIP on junior/need_help_xyzzy branch; please take a look and help merging it."

Such a "push -f" to split heads (or pushing to need_help branch and ask others to do the "pull/push" for him) shouldn't be a norm, and if a project _relies_ on the ability to do so, there probably is a deeper problem with the project (e.g. perhaps the codebase is not modularized enough to allow isolated parallel development by junior people on narrow subparts of it).