[PATCH 0 of 3] update: allow crossing branches

Stuart W Marks smarks at smarks.org
Thu Aug 20 00:57:43 CDT 2009


Last week there was a thread discussing the behavior of 'hg update'
crossing branches. See the thread starting here:

http://www.selenic.com/pipermail/mercurial/2009-August/027139.html

As things currently stand, when there are no outstanding changes,
'update' will allow crossing to another named branch but will disallow
crossing to another (topological) branch within the same named
branch. Several of us thought this restriction unnecessary. Here's a
patch series to address this issue.

1. The first patch is a test-only patch. The combinations of
linear and crossing branches, no/-c/-C option, absence/presence of
uncommitted changes, and absence/presence of a specific rev resulted
in about 30 different cases. I wanted all of these to be tested first
to ensure that subsequent patches didn't inadvertently break anything.

See tests/test-update-branches if you want to see all the cases.

2. This contains the actual logic change to allow crossing to another
branch within the same named branch, along with a clarification of an
error message in this area. 

This patch also contains a bit of logic to disallow simultaneous use
of update -c and -C, which don't actually make sense used
together. This patch further updates the tests introduced in the
previous patch, as well as updating a couple other tests whose output
was changed by this patch.

With this change, all the behaviors of updating across the "same"
vs. "different" named branch are now identical. I preserved these
extra cases. I could simplify the test by collapsing these cases, if
people think that's the right thing to do.

Hat tip to Gilles Moris for posting a similar patch a couple weeks
back that otherwise received no attention:

http://www.selenic.com/pipermail/mercurial/2009-July/026914.html

3. The third patch updates the help text for 'hg update' to reflect
the new behavior and to clean it up significantly.

Please review and comment.

s'marks


More information about the Mercurial-devel mailing list