[PATCH] update: introduce config option ui.allowdirtyupdate for dirty nonlinear updates
Gabor.STEFANIK at nng.com
Tue Dec 13 11:48:51 EST 2016
This message, including its attachments, is confidential. For more information please read NNG's email policy here:
By responding to this email you accept the email policy.
> From: Augie Fackler [mailto:raf at durin42.com]
> Sent: Thursday, December 8, 2016 4:02 PM
> To: Gábor STEFANIK <Gabor.STEFANIK at nng.com>
> Cc: Jun Wu <quark at fb.com>; mercurial-devel <mercurial-devel at mercurial-
> Subject: Re: [PATCH] update: introduce config option ui.allowdirtyupdate for
> dirty nonlinear updates
> On Thu, Dec 8, 2016 at 9:13 AM, Gábor STEFANIK
> <Gabor.STEFANIK at nng.com> wrote:
> > ----------------------------------------------------------------------
> > ---- This message, including its attachments, is confidential. For
> > more information please read NNG's email policy here:
> > http://www.nng.com/emailpolicy/
> > By responding to this email you accept the email policy.
> > -----Original Message-----
> >> From: Jun Wu [mailto:quark at fb.com]
> >> Sent: Wednesday, December 7, 2016 6:44 PM
> >> To: Gábor STEFANIK <Gabor.STEFANIK at nng.com>
> >> Cc: mercurial-devel <mercurial-devel at mercurial-scm.org>
> >> Subject: Re: [PATCH] update: introduce config option
> >> ui.allowdirtyupdate for dirty nonlinear updates
> >> Excerpts from Gábor Stefanik's message of 2016-12-07 16:56:09 +0100:
> >> > # HG changeset patch
> >> > # User Gábor Stefanik <gabor.stefanik at nng.com> # Date 1481126137 -
> >> > # Wed Dec 07 16:55:37 2016 +0100
> >> > # Node ID dabbe365b843fcf9b8a0de6c08e9db6100b391e9
> >> > # Parent 6472c33e16326b8c817a8bae0e75053b19badb2c
> >> > update: introduce config option ui.allowdirtyupdate for dirty
> >> > nonlinear updates
> >> >
> >> > Make it easier to test codepaths common to graft and update without
> >> > having to mess around with obsolete markers to force a nonlinear
> >> > Named by analogy with ui.allowemptycommit.
> >> >
> >> > diff -r 6472c33e1632 -r dabbe365b843 mercurial/merge.py
> >> > --- a/mercurial/merge.py Mon Dec 05 17:40:01 2016 +0100
> >> > +++ b/mercurial/merge.py Wed Dec 07 16:55:37 2016 +0100
> >> > @@ -1536,7 +1536,10 @@
> >> >
> >> > if pas not in ([p1], [p2]): # nonlinear
> >> > dirty = wc.dirty(missing=True)
> >> > - if dirty or onode is None:
> >> > + # experimental config: ui.allowdirtyupdate
> >> > + if repo.ui.configbool('ui', 'allowdirtyupdate', False):
> >> I think experimental config options are usually under the "experimental"
> >> section.
> > Format.generaldelta was also experimental.
> > Grepping through the repo for "experimental config", I'm under the
> > impression that "experimental" is to be used for options that can't be
> > cleanly categorized under any existing sections, and don't warrant
> introducing a new section.
> [experimental] is also for things that aren't sure to be supported forever.
> > This is experimental for now, since we need to support "hg update
> > --abort" to make this safe for users, but eventually I hope to get
> > this de-experimentalized and maybe even enabled by default. It would
> > be better not to break backwards compatibility just because this becomes
> no longer experimental.
> Until we're confident that this feature will live forever, it should be in
I would argue that this will live forever, because:
a) If we eventually decide to make this the default, some users will want to
still have the old behavior - which they can get by explicitly setting
ui.allowdirtyupdate=False. I don't envision ever dropping the current behavior
b) If we decide that nonlinear merge updates shall never be supported using
the "update" command for whatever reason, we will still need it for the same
debugging uses that we have now.
This is as likely to live forever as merge.preferancestor, which is also marked
with "experimental config:", but not in [experimental].
In terms of backwards compatibility, I would also argue that we shouldn't use
[experimental] for options that _may_ live forever either, only for those
that are guaranteed to be temporary (e.g. experimental.bundle2-exp, which
is to be removed as bundle2 becomes mandatory for GD->GD clones):
An "experimental, may live forever" option can have 2 outcomes:
a) it's dropped before it matures, which is always a BC break, or
b) it matures, and loses its experimental status.
With a), it doesn't matter if we use [experimental] or the appropriate regular
section - the outcome is always a BC break. With b), going straight for the final
intended section is a clear BC win - those using the experimental-era option
won't have to change anything when it matures, whereas if we initially use
[experimental], then move the option to another section once mature, everyone
using [experimental] in their hgrcs needs to take action (or we must keep the
[experimental] version as alias).
I know we don't offer BC guarantees for experimental and debug features, but
I would still argue against gratuitously breaking BC for no gain.
> >> > + pas = [p1]
> >> > + elif dirty or onode is None:
> >> > # Branching is a bit strange to ensure we do the minimal
> >> > # amount of call to obsolete.background.
> >> > foreground = obsolete.foreground(repo,
> >> > [p1.node()])
> > _______________________________________________
> > Mercurial-devel mailing list
> > Mercurial-devel at mercurial-scm.org
> > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
More information about the Mercurial-devel