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

[Gilles Moris]

Le 30/05/2015 03:29, Pierre-Yves David a écrit :
>
>
> 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."
>

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

Regards.
Gilles.