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

Laurent Charignon lcharignon at fb.com
Tue Jun 2 19:25:33 CDT 2015

I have sent a V2 taking into account the requested changes.
Jordi, how do you feel about Pierre-Yves' argument for this patch?



On May 31, 2015, at 1:03 PM, Pierre-Yves David <pierre-yves.david at ens-lyon.org<mailto:pierre-yves.david at ens-lyon.org>> wrote:

On 05/30/2015 02:28 AM, Gilles Moris wrote:
Le 30/05/2015 03:29, Pierre-Yves David a écrit :

On 05/28/2015 03:26 PM, Matt Mackall wrote:


> 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.

Lets write some history here...

In the dawn of time, the behavior was:
 hg fold <revset>
-> fold everything in <revset> together.
 (This match the `hg fold start::end` from Matt.)

There was two issue with this UI:

1) It pretty much requires the knowledge of revset to be used
efficiently. This put the barrier of entry higher than necessary for a
fairly basic command.

2) The most common case turned out to be, I want to fold the last N
commits. This happen commonly when one is working toward something,
making frequent wip commit along the way to be able to easily go back
to a check point. So the common case was `hg fold X::.`

(This two principle seems important to: (1) do not requires revset
knowledge to ensure a low barrier of entry (2) default case should be

So, we move the default to :

 hg fold <rev>
-> fold everything between '.' and <rev>.

 hg fold --exact <revset>
 -> fold everything in the revset.

I think that putting the advanced use case of 'folding anywhere' is an
okay choice.

Most of mercurial command behave according the working directory parent

- commit -> make a commit as child as '.'
- amend -> add content to '.'
- uncommit -> remove content to '.'
- hg split -> split '.' into multiple changeset (in the future)
- diff -> show difference with '.'
- revert -> restore file as in '.'
- merge -> merge '.' with something else
- rebase -> rebase '.' somewhere else (by default)
- graft -> get a new commit on top of '.'
- histedit -> histedit from '.' to X
 (would be nice to have an '--exact' here actually)
- hg evolve -> evolve stuff related to '.'

So I think it at most sensible (and at best consistent) with the other
commands than the default involves the working copy.

[former message start]

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.

I believe "8+7" is only used here as an example. It is a place holder
for 'anycomplicatedrevset()'. In that case, the revset result could be
said "visually obvious" but the internal code have no clue about.

My personal philosophy is:

 "We should lever change behavior accord length of a revset result"

When I run a command with '::myfeature - public()' I dunno if this is
going to return 0, 1, 2 or N changeset. But I still want to be able to
build alias for it and run command without double checking revset
lengh. Therefore, command cannot change there behavior regarding
revset query result because that will blow in my face all the time.

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

Why would anybody type that rather than:

 hg fold --chain 7

CF, previous comment. Nobody is going to type 7+8. But revset result
will be 7+8

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

I am not convinced that it needs 2 flags, or even 1.

Forgetting about the current UI, we could expect that providing a single
commit would fold up to the working dir. If a complex revset is
provided, I guess the power user could do "first(revset)". If we really
want a flag for safety, we could use -f/--from: "hg fold -f 7".
Then if a revset yields multiple commits, I would expect the --exact

I'll insist on the fact we cannot rely on 'number of commit' because revset is not "predicable enough".

Basic user will start provided simple revsets with "non-predicable" result, and you should not expect them to be smart enough to add "first" like element to it until it suddenly break for unclear (to them reason) and stop trusting the tool.

Moreover, You have way to force the 'multiple -> one' way. But you have no way to go the other way. Lets look at this command command:

- hg fold --exact 'draft() and ::mybook'

Current behavior (with --exact)

revs | result
0-1 | abort 'nothing to fold here'
2+  | fold all revs together

This is a safe sensible and predictable behavior.

With 'auto detect revset size proposal'

revs | result
0   | abort 'no rev'
0-1 | fold 'revs::.'
2+  | fold all revs together

This is unpredictable behavior that will blow in people face.

So, think of the children, do not relying on the size of the revset result.

Pierre-Yves David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150603/780998e4/attachment.html>

More information about the Mercurial-devel mailing list