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

Boris Feld boris.feld at octobus.net
Fri Nov 3 15:29:34 EDT 2017


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.

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.


More information about the Mercurial-devel mailing list