[PATCH 2 of 2] rebase: add flag to require destination

[Ryan McElroy]

(Sorry for the late reply; I just found this in my drafts folder)


On 3/14/17 6:19 PM, Pierre-Yves David wrote:
> On 03/13/2017 11:35 PM, Gregory Szorc wrote:
>>
>>
>>> On Mar 13, 2017, at 20:15, Augie Fackler <raf at durin42.com> wrote:
>>>
>>> (+martinvonz,marmoute for my probably-bad idea)
>>>
>>>> On Mar 13, 2017, at 20:14, Ryan McElroy <rm at fb.com> wrote:
>>>> On 3/12/17 5:48 PM, Gregory Szorc wrote:
>>>>
>>>>> On Sun, Mar 12, 2017 at 12:06 PM, Augie Fackler <raf at durin42.com> 
>>>>> wrote:
>>>>>> On Sat, Mar 11, 2017 at 06:03:13PM -0800, Ryan McElroy wrote:
>>>>>> # HG changeset patch
>>>>>> # User Ryan McElroy <rmcelroy at fb.com>
>>>>>> # Date 1489283611 28800
>>>>>> #      Sat Mar 11 17:53:31 2017 -0800
>>>>>> # Node ID 7c7f442027b6a0cd51b1f06b01913f53f4f9e9cd
>>>>>> # Parent  a788a4660443dfc33c5c1c58eec78e20150404d9
>>>>>> rebase: add flag to require destination
>>>>>
>>>>> These both look mechanically fine to me, but I'm a little skeptical
>>>>> about the configuration sections in play (update and rebase
>>>>> respectively), so I'll leave them for other parties to examine and 
>>>>> bikeshed.
>>>>>
>>>>> The ship has likely already sailed, but IMO it would be nice if 
>>>>> there a unified [command] (or similar) section that controls 
>>>>> behavior of commands, specifically with regards to command 
>>>>> arguments. But, a section per command sharing the name of the 
>>>>> command is acceptable. I just don't think options for command 
>>>>> argument behavior appearing in random sections is very user friendly.
>>>>
>>>> A possibility is to group them all under the same section, but lets 
>>>> please have it *not* be ui, which is already super overloaded.
>>>>
>>>> I think pyd suggested a "[behavior]" section for this kind of 
>>>> thing. I'd be happy to send a v2 with this format:
>>>>
>>>> """
>>>> [behavior]
>>>> rebase.requiredest = True
>>>> update.requiredest = True
>>>> """
>>>>
>>>> (Both would still default to false of course)
>>>>
>>>> What do you think of this proposal?
>>>
>>> Seems good. Feels like a good place for per-command pager 
>>> enable/disable as well? And maybe also Martin's new merge config 
>>> knob...
>>>
>>> What do people think about that as a place to collect those types of 
>>> things?
>>
>> I feel obligated to bikeshed "behavior" because it is too ambiguous. 
>> Literally every config option influences "behavior." That's the 
>> definition of a config option.
>
> For the record, "behavior" poped in my mind as a candidates because 
> all these knob introduces "behavior changes", the things we are 
> usually careful to not introduce.
>
>> I still like [command] for options influencing the behavior of 
>> commands. To a user, it is obvious the section is influencing the 
>> behavior of commands and not something else.
>
> If I understand your proposal correctly, you are offering one section 
> per commands: (eg: "[update]", "[rebase]")
>
> This will lead to many very small section which I find detrimental. I 
> think having similar option into the same section great improve their 
> discoverability because they will be together in the help. So I'm not 
> excited about further config section fragmentation.
>
>> A bonus to making the section specific to commands is we can do 
>> things like tell the user when they have options belonging to 
>> uninstalled commands with lower risk of a false positive. We could 
>> potentially also hook up command argument processing directly to a 
>> section that maps to the command name without fear of of collisions 
>> from non-command things.
>
> I think we can achieve the same things using a single section section 
> with a command specific prefix. eg:
>
>  [behavior-or-whatever]
>  update.auto-destination=False
>  update.auto-merge=False
>  rebase.auto-destination=True
>  commit.allow-empty-diff=True
>
> (So that's seems like a good idea, but we can achieve it in both cases)
>
>

If you see my v2, there's a single section called literally "[commands]" 
that controls the behavior of these -- I think that's what indygreg was 
asking for (but maybe I'm wrong). Regardless, this fits the "single 
section" idea you had, right marmoute?

Cheers,

~Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170320/5d5c7a84/attachment.html>