[PATCH evolve-ext] fold: add argument to handle ambiguous case
pierre-yves.david at ens-lyon.org
Fri May 29 20:29:20 CDT 2015
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 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
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."
More information about the Mercurial-devel