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.da...@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.da...@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.da...@ens-lyon.org <mailto:pierre-yves.da...@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 <martinv...@google.com
<mailto:martinv...@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
- 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.
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).
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.
In all case, that discussion is getting deeper and we should switch to VC.
[…]
--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
