This ended up long, because I’m riffing a bit on what it means to be experimental etc. If you don’t care about those details (most readers of this list probably don’t?), skip to the “TL;DR:” bit and let’s talk about footguns now that the bikeshed is painted...
> On Dec 13, 2016, at 11:48 AM, Gábor STEFANIK <gabor.stefa...@nng.com> wrote: > > -----Original Message----- >> On Thu, Dec 8, 2016 at 9:13 AM, Gábor STEFANIK >> <gabor.stefa...@nng.com> wrote: >>> >>> -----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 [...] >>> >>> 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 (By this point it wouldn’t be experimental...) > , 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. Yep! That’s very true. Note that if we were going to try and move the default (or even the recommended setting), I’d probably bias in the other direction: making something like --check the default, in the name of greater safety. The only way I can see that changing would be if we had some fast-but-reliable way to undo an in-progress update that hit merge conflicts. > 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. I guess I don’t know what those cases are. Any examples that’d help me understand the use case? > This is as likely to live forever as merge.preferancestor, which is also > marked > with "experimental config:", but not in [experimental]. It may interest you to know that preferancestor predates the existence of [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 It’s explicitly *not* a BC break as hg defines BC. That’s the point of experimental: we can discard the experiment after a long field trial without having to carry the baggage forever. > , 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). Yep, that’s a real pain point. We definitely felt it on some things. I suppose I could be happy with leaving this in [ui] given that it’s something I don’t expect to have on by default as long as it’s prominently labelled in any documentation as experimental, and that we reserve the right to take it out if it ends up being too costly to maintain or too much of a footgun for users. We probably ought to document when to use [experimental] vs documenting something as experimental. I’m no expert, but this patch has certainly been an interesting foil for the thought process. > 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. Nitpick: there’s almost always gain in that we get to throw away code. TL;DR: I’m not unsympathetic to your concerns, but this particular feature worries me in terms of user support load just on its face. Does that make sense? I’m trying to play a 20-year-horizon usability-and-safety game here, as well as a 20-year-horizon maintainability game. I think in the process of writing this email, I’ve convinced myself that [ui] with copious experiment warnings is the right location, but that I’m worried about the existence of the config knob at all. Not sure what to say, other than to ask if you can allay my fears that this feature is a massive footgun waiting to happen. Thanks! Augie _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
