On Fri, Jan 6, 2017 at 7:12 AM, Pierre-Yves David <pierre-yves.da...@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.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
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 _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel