[PATCH evolve-ext] fold: add argument to handle ambiguous case

Matt Mackall mpm at selenic.com
Thu May 28 17:26:40 CDT 2015

On Thu, 2015-05-28 at 14:01 -0700, Laurent Charignon wrote:
> # HG changeset patch
> # User Laurent Charignon <lcharignon at fb.com>
> # Date 1432845532 25200
> #      Thu May 28 13:38:52 2015 -0700
> # Node ID 0821817a84792210498107777181dcc9f1d68ec7
> # Parent  69e5de3e6129185469c2cbf98383ac6d58260d0c
> fold: add argument to handle ambiguous case
> Before this patch, when a user was using fold for the first times he could
> think that --exact is the default behavior and make a mistake.
> For example hg fold -r 12+13 won't just fold revision 12 and 13 together but
> 12, 13 and the linear chain of revision upto the working directory's parent.
> This patch introduces a new option when the selection is ambiguous: when the
> user specified two or more revisions not including the working copy's parent
> without using --exact flag.
> When the user is giving only one revision we assume that the intent of the user
> is clearly to fold the chain from that revision up to the working directory's
> parent. Example of change assuming that we have a linear history from rev 1 to
> 10 and the working copy parent is 10:
> hg fold 9 # will fold 9 and 10 together, unchanged


> hg fold 8 + 7 # before was folding 7,8,9,10, now prints an error

What is the user story where this is what's wanted? If the answer is
"never" (which I suspect), then we should just make this do what's
expected: fold the specified versions with each other.

> hg fold 8 + 7 --chain # folds 7,8,9,10 together

Why would anybody type that rather than:

 hg fold --chain 7

Adding + 8 doesn't add any additional info except maybe "I'm trying to
do something different and am about to have a sad."

It seems to me that both --exact and --chain are unnecessarily
complicated. We should really consider an interface that's simply:

 hg fold start::end

with no magic defaults.

Mathematics is the supreme nostalgia of our time.

More information about the Mercurial-devel mailing list