[PATCH evolve-ext] fold: disallow multiple revisions without --exact

Fri Jan 6 12:03:27 EST 2017

On Fri, Jan 6, 2017 at 7:12 AM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> On 01/04/2017 10:47 PM, Martin von Zweigbergk wrote:
>>
>> On Wed, Jan 4, 2017 at 11:40 AM, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org> wrote:
>>>
>>> On 01/04/2017 05:38 PM, Martin von Zweigbergk wrote:
>>>>
>>>> On Wed, Jan 4, 2017 at 4:53 AM, Pierre-Yves David
>>>> <pierre-yves.david at ens-lyon.org> wrote:
>>>>>
>>>>> On 12/18/2016 06:36 PM, Martin von Zweigbergk via Mercurial-devel
>>>>> wrote:
>>>>>>
>>>>>> On Fri, Dec 16, 2016, 23:53 Pierre-Yves David
>>>>>> <pierre-yves.david at ens-lyon.org
>>>>>> <mailto:pierre-yves.david at ens-lyon.org>>
>>>>>> wrote:
>>>>>>     On 11/05/2016 12:58 AM, Martin von Zweigbergk via Mercurial-devel
>>>>>> wrote:
>>>>>>     > # HG changeset patch
>>>>>>     > # User Martin von Zweigbergk <martinvonz at google.com
>>>>>>     <mailto:martinvonz at google.com>>
>>>>>>     > # Date 1478303512 25200
>>>>>>     > #      Fri Nov 04 16:51:52 2016 -0700
>>>>>>     > # Node ID bb80851fe9a6e14263f0076074108556377141f9
>>>>>>     > # Parent  cb2bac3253fbd52894ffcb4719a148fe6a3da38b
>>>>>>     > fold: disallow multiple revisions without --exact
>>>>>
>>>>> […]
>>>>>
>>>>>
>>>>> Currently I would weight "constraint" that way
>>>>> (more important to least important):
>>>>>
>>>>>  (1) no revset knowledge required:
>>>>>          simplicity is very important,
>>>>
>>>>
>>>> That makes sense, but note that "hg fold -r foo -r bar" is already
>>>> supported and does not require the user to know about revsets (and one
>>>> can also drop the "-r"s in that command). I feel like you're assuming
>>>> that defaulting to --exact requires the user to know about revsets. I
>>>> don't see it that way.
>>>
>>>
>>> The "specify multiple revs" approach "works" but is quickly cumbersome
>>> and
>>> error prone if you have more than a couple changesets.
>>>
>>> There is currently two others tools that someone can use to fold
>>> changesets:
>>>  * hg rebase --collapse
>>>  * hg histedit
>>> Both provide the user with a simple way to fold many changesets (eg: by
>>> providing a root). So a kind of bottom line here is that it would be
>>> really
>>> awkward if the command dedicated to folding changeset end up being less
>>> user
>>> friendly than command dedicated to other usecase (that happen to be able
>>> to
>>> fold things as a secondary feature).
>>>
>>> This made me implicitly discard the option to "list every single
>>> changeset
>>> to be folded" from the "viable UI" list.  Thanks for pointing this out.
>>> It
>>> gave me the chance to unearth that extra criteria: "be a better UI than
>>> the
>>> existing solution".
>>>
>>> What do you think ?
>>
>>
>> Thanks for mentioning rebase. Rebase has various ways of specifying
>> which revisions to rebase (-b,-s,-r). It also has a default, which I
>> consider a mistake.
>
>
> Actually, rebase has two defaults:
>
> - The default destination:
>     It used to be pretty bad, working only in the simplest case and being
> harmful in all the others. However, this actually got fixed last year and it
> now pretty okay. It even has the potential to become pretty awesome once we
> have a good story regarding feature branches and names. See associated wiki
> page for details:
> https://www.mercurial-scm.org/wiki/DefaultDestinationPlan

This is the one I was referring to. I'm happy with the default rebase set.

>
> - The default rebase set: (-b .)
>     It seems to fit the needs in most case and I don't think I've seen much
> complains about it. We can probably improve that a bit when we get a good
> "current working set" story through feature branch.
>
> I agree that bad default are mistake, but good default are great and have
> been a good advantage of Mercurial. We should keep aiming at good default
> whenever we can.

Oh, definitely. I liked git's default destination and relied on it all
the time. See https://github.com/git/git/commit/15a147e61898d25ec8b539190e87f3a09592c9c8
:-)

>
>> So, how about making "hg fold" not have a default?
>> I suggest we ask the user to say either "hg fold --from=$rev" to get
>> the behavior they currently get by default, and "hg fold -r $revset"
>> (or "hg fold -r $rev1 -r $rev2" for beginners). Note that I'm
>> suggesting that --exact will not be needed (and can be deprecated),
>> because I don't like to have the argument passed to -r be used for
>> different things based on that flag. How does that sound?
>
>
> The --from things is to consider, it seems to match our current constraint
> including the one about not being worse than the existing solution (It does
> not strike me as much better, but at least not worse). Not sure about the
> word since we might want to allow it to specify descendant too (not just
> ancestors).

We could also add a --to, but that seems like something that would be
used very rarely. Leave it out for now?

>
> I'm not sure what you mean with the --rev flag. Do you mean that default
> entry would be revset? Or that --rev would trigger the revset mode? or
> something else? Previous discussion on the topic concluded that having mode
> switch on --rev wasn't a good idea.

Examples to clarify what I mean:

$ hg fold .^
hg fold: invalid arguments
hg fold [--from REV] [--rev REV]...
$ hg fold --from .^ # folds .^ and .
$ hg fold --from .^ -r .
hg fold: invalid arguments
hg fold [--from REV] [--rev REV]...
$ hg fold -r .^
warning: asked to fold a single revision; nothing to do
$ hg fold -r .~2 -r .~1 #folds those two (and leaves .)
$ hg fold -r .~2::.~1 #folds those two (and leaves .)

>
> In all case, that discussion is getting deeper and we should switch to VC.
>
>>> […]
>
>
> --
> Pierre-Yves David