RFC: allow "hg merge" to take a URL argument, add autocommit option

Vadim Lebedev vadim at mbdsys.com
Tue Jun 20 12:05:11 CDT 2006


Bryan O'Sullivan wrote:

>I've been noticing that new users seem to have a hard time with
>Mercurial's model for merging changes, probably because there are too
>many steps involved.
>
>Here's an example.  I've got some changes in my repo, and I want to get
>whatever is upstream.  The normal cycle runs like this:
>
>Get remote changes:
>    hg pull URL
>See if the output of pull told me I have new heads.  If yes:
>    hg merge
>    hg commit
>
>I find that new users are not thinking in terms of "where are the
>parents of the working directory?" prior to a merge, because this is not
>a familiar concept, and is not well documented in any case.
>
>Other hazards to usability:
>      * there are multiple steps involved - pull, merge, commit
>      * people have to manually edit a commit message that is *always*
>        boilerplate (there are 93 instances of "merge with crew" as the
>        commit message in the crew repo)
>
>I propose that the behaviour of the merge command be enhanced as
>follows.
>
>If given no arguments, or given a revision ID (or tag, or what have
>you), it behaves exactly as it does now.
>
>If given a URL as an argument, it pulls changes from that URL, and
>either updates the working dir if there have been no heads added, does a
>merge if there is one added head, and does no merge or update (but
>prints a message saying why) if there are more than one added heads.
>
>If given a "-c" option, it commits the result of a successful merge
>immediately, with an autogenerated commit message.
>
>This doesn't reduce the functionality of "merge" in any way, but it
>eliminates two annoying steps and a visit to the editor.  For many
>people, the default way to get and merge with upstream changes will then
>become "hg merge -c URL".
>
>I realise that this may not fit with some people's beliefs about how
>software should be developed, i.e. you should examine incoming changes
>before you merge with them, and test the result of a merge before you
>commit it.  However, you still get to do both of those with these
>changes, but the workflow is streamlined for people who prefer a looser
>development strategy.
>
>Comments?
>
>  
>
I'd suggest that hg pull -m  will do the stuff you describe

Vadim


More information about the Mercurial mailing list