[PATCH RFC] revert: no longer mark --interactive as experimental

Martin von Zweigbergk martinvonz at google.com
Fri Nov 3 15:36:03 EDT 2017


On Fri, Nov 3, 2017 at 12:29 PM, Boris Feld <boris.feld at octobus.net> wrote:

> 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 <denis at laxalde.org>
> > > wrote:
> > >
> > > > Augie Fackler a écrit :
> > > >
> > > > >
> > > > > On Nov 2, 2017, at 09:39, Martin von Zweigbergk via Mercurial-
> > > > > devel <
> > > > > > mercurial-devel at 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.
>

As I said, I suggested "hg grab" a long time ago and no one seemed
interested. So I'd say consensus (i.e. that most people, not all, agree) is
the patch from Denis that I queued earlier today.


>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20171103/8bd60e43/attachment.html>


More information about the Mercurial-devel mailing list