<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 16, 2016 at 10:29 AM, Pierre-Yves David <span dir="ltr"><<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank">pierre-yves.david@ens-lyon.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 09/14/2016 05:11 AM, Augie Fackler wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
# HG changeset patch<br>
# User Augie Fackler <<a href="mailto:augie@google.com" target="_blank">augie@google.com</a>><br>
# Date 1472584421 14400<br>
#      Tue Aug 30 15:13:41 2016 -0400<br>
# Node ID 828f260114a3a55e246cb5de434e75<wbr>bdc782e4ad<br>
# Parent  600be3c9acee0ec14bd19c032cc048<wbr>0e4501fe8c<br>
fancyopts: disallow true as a boolean flag default (API)<br>
<br>
This was nonsense, as there's not been a way for the user to<br>
un-specify the flag. Restricting this behavior will open the door to<br>
some nice fit-and-finish functionality in a later patch, and shouldn't<br>
break any third party extensions. This is marked as (API) since it<br>
might break a third party extension, but given the fact that it was<br>
silly before that's mostly a formality.<br>
</blockquote>
<br>
I really wish we had details on this as requested in the review of the previous version. Especially because I remember that forbidding 'True' as default was making other improvement hard so I'm not sure why we have to do this.<br>
</blockquote>
<br>
Err? I'm not sure what you're asking for now, and I definitely didn't understand it on the last go round.<br>
</blockquote>
<br></span>
Okay, let me clarified, My question here is:<br>
<br>
Why is this problematic to have default to 'True Value'<br>
<br>
<br>
You refered this as """These cases are a bit problematic, because we don't really have a way to specify default-true flags""" in<br>
<a href="https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-September/087968.html" rel="noreferrer" target="_blank">https://www.mercurial-scm.org/<wbr>pipermail/mercurial-devel/2016<wbr>-September/087968.html</a><br>
<br>
I'm seeing another avatar of this question when you says "Restricting this behavior will open the door to some nice fit-and-finish functionality in a later patch" in the current thread. I would like details on this "nice fit-and-finish" features.<br>
<br>
Does this clarify my question ?</blockquote></div><br><br></div><div class="gmail_extra">Sure. The answer (which I can fold into the log message if you think it's important) is that because of how opts make it into diffopts, we can't rely on opts to not be filled in for a value that was unspecified on the command line. Because of that, we need to find a backwards compatible way to thread defaults through such that they can be identified as defaults. The easy way out is to use None for default and False for explicitly-false.<br><br></div><div class="gmail_extra">I'm open to other solutions on the tri-state, but it's a significant piece of work that I don't really want to take on.<br></div></div>