>
-------------------------------------------------------------------------- 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: Augie Fackler [mailto:r...@durin42.com] > Sent: Thursday, December 8, 2016 4:02 PM > To: Gábor STEFANIK <gabor.stefa...@nng.com> > Cc: Jun Wu <qu...@fb.com>; mercurial-devel <mercurial-devel@mercurial- > scm.org> > 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.stefa...@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:qu...@fb.com] > >> Sent: Wednesday, December 7, 2016 6:44 PM > >> To: Gábor STEFANIK <gabor.stefa...@nng.com> > >> Cc: mercurial-devel <mercurial-devel@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.stefa...@nng.com> # Date 1481126137 - > 3600 > >> > # 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 > update. > >> > 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 > experimental. 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 completely. 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@mercurial-scm.org > > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
