[PATCH evolve_ext V2] fold: take an explicit list of revisions (BC)

[Pierre-Yves David]

TL;DR; new user (1) are working copy centric and should (2) should not 
be exposed to "revset" when unnecessary.

On 06/24/2014 02:02 AM, Greg Ward wrote:
> On 23 June 2014, Pierre-Yves David said:
>> On 06/22/2014 04:52 PM, Greg Ward wrote:
>>> # HG changeset patch
>>> # User Greg Ward <greg at gerg.ca>
>>> # Date 1403481137 14400
>>> #      Sun Jun 22 19:52:17 2014 -0400
>>> # Node ID 4ab7a80fc11f275c03d4ddb94936a0688b71e6bc
>>> # Parent  2fbba0bf7e7c8cbff1f94bc95c4d6214df85ef81
>>> fold: take an explicit list of revisions (BC)
>>
>> No thanks.
>
> Darn. I guess I misunderstood our previous discussion about this.
>
>> This use the be the default and ended up being very confusing. The
>> vast majority of fold operation involve the working directory and an
>> ancestors (something a descendant). The default should reflect that.
>> Also, we should not requires user to have a PhD in revset to use Mercurial.
>
> "REV::" is not a PhD-level revset.

Ok, it's not a super complicated revset, but it is a revset (or at least 
a "magic" invocation.

The principle I'm defending here is "simple action should be simple to 
do". Fold is a command that also target new user with basic knownledge 
of mercurial. I strongly believe those users should not be exposed to 
".^::." if we can avoid it.

As a side benefit, delaying the exposure to "x::y" lower the odds user 
will confuse it with "x:y" and saws his own leg by mistake.

>> So, I'm deeply convince the default should be "fold between . and REV".
>
> OK, fine. I happen to disagree, but whatever.

The logic here is that people usually works from a working copy perspective.

commit: record they working copy,
merge:  add other change in they working copy,
update: change content of working copy to anyther changeset,
rebase: (by default) move changesets under working copy to another head,
graft:  get a commit and put it on the working copy parent,
tag:    tags the working copy parent
revert: put content in the working copy parent

(we can also add uncommit to the list)

You have to be a fairly advance user of Mercurial to start thinking 
about the whole graph and performs more abstract action to change its 
shape. I believe such users will have no trouble using a special flag in 
such case.

The first version of fold had the behavior you describe, but seeing tens 
of Logilab people using it convinced me that the current default was a 
better choice for new users. The few usage of `hg fold` I'm seeing at 
facebook goes in the same direction.

>> How ever I agree than having different behavior for `hg fold REV`
>> and `hg fold --rev REV` sucks.
>
> OK, I'll see if I can fix that.
>
>> I also agree that the "do an in
>> memory fold of unrelated changeset" usecase is nice. We should think
>> about a dedicated flag for this case.
>
> --only? Example usage:
>
>    hg fold --only R1 R2 ... Rn
>
> combines R1, R2, and Rn to make a new changeset.

"--only" would work. JordiGH is proposing "--exact"

I'm fan of neither but I think I like --exact more.

-- 
Pierre-Yves David