On Fri, 2017-11-03 at 14:57 +0100, Denis Laxalde wrote: > Martin von Zweigbergk a écrit : > > On Thu, Nov 2, 2017 at 7:16 AM, Denis Laxalde <de...@laxalde.org> > > wrote: > > > > > Augie Fackler a écrit : > > > > > > > > > > > On Nov 2, 2017, at 09:39, Martin von Zweigbergk via Mercurial- > > > > devel < > > > > > mercurial-devel@mercurial-scm.org> wrote: > > > > > > > > > > Can we still change the behavior of "hg revert -i -r" to show > > > > > a to-apply > > > > > diff, not a to-revert diff? (There's a bug number I'm too > > > > > lazy to look up > > > > > from mobile.) > > > > > > > > > > > > > I thought we had already done the patch-reversing that we felt > > > > was > > > > required... > > > > > > > > > > The last discussion ended with a status quo: > > > > > > https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-Nove > > > mber/090142.html > > > > > > Since then, I set > > > "experimental.revertalternateinteractivemode=false" to > > > have a behavior that I find meaningful in most situations. > > > > > > So do I. The problem is that new users won't have that. If we're > > graduating > > --interactive now, then this seems like a good time (at the latest) > > to > > switch the default of that flag. > > > > > > > The only case > > > it does not work well is "hg revert -i -r .^" (which I think was > > > a major > > > motivation for the current behavior).
We think that `hg revert -i and `hg uncommit -i` are both useful and couldn't be replace by the other. They are different in 3 points: - hg uncommit works on the current directory parent while hg revert -i -r .^ could works on other changesets. - hg uncommit modify the current directory parent and keep the changes in the current working directory while hg revert is only modifying the current working directory - hg uncommit use-case is to remove something from a commit (like some parts that really should be in their own changeset) while hg revert use-case is try to revert a changeset in your history and see the impact (like are the tests passing now that I reverted these two lines). > > > > > > I prefer the forward direction even when reverting to a parent. We > > could > > add --no-forward-patch flag or something, or we could add a "hg > > grab" that > > grabs the file content from a revision and is equivalent to "hg > > revert" > > except that the patch is always forward. But last time I suggested > > that, no > > one seemed interested, so I'm not very optimistic. So probably just > > switch > > the default of revertalternateinteractivemode to false? > > I can resurrect the patch above linked above which drops the option > and > use the "apply" verb instead of "revert". Just let me know. We think that keeping both `hg revert -i` and `hg uncommit -i` in their current state is the way to go, as they works on a different target, they solves different use-cases and one is the not the subset of the another. Another dedicated command seems semantically better for this specific use-case, maybe grab is not the best name. It is used by the evolve extension for another purpose. If not a new command, a new command-line flag or something in the interface would be good enough to be discoverable by users. If there are a command line flag. It make sense to have the associated boolean config in the [commands] section. Maybe revert.interactive- patch-direction. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
