[PATCH evolve-ext] fold: add argument to handle ambiguous case
gilles.moris at free.fr
Sat May 30 04:28:26 CDT 2015
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
More information about the Mercurial-devel