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

Bryan O'Sullivan bos at serpentine.com
Tue Jun 20 11:30:45 CDT 2006


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?

	<b



More information about the Mercurial mailing list