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

[Pierre-Yves David]

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

[reordered]

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


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

-- 
Pierre-Yves David