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

[Martin von Zweigbergk]

On Mar 13, 2017 20:16, "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?


Putting my new config there seems like the obvious thing to do once it's no
longer experimental​ (or once config options can be tagged as experimental,
if someone decided to work on that). [behavior] sounds good to me.

I also like the spirit of the patch. We currently have something similar
internally that we can remove once this is in. Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170313/15987cb5/attachment.html>