[PATCH 2 of 2] exchange: refactor push so that extensions can wrap pushop

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Oct 15 12:15:03 CDT 2015



On 10/15/2015 06:13 PM, Gregory Szorc wrote:
> On Thu, Oct 15, 2015 at 3:28 AM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
> wrote:
>
>
>
>     On 10/15/2015 07:03 AM, Sean Farley wrote:
>
>         # HG changeset patch
>         # User Sean Farley <sean at farley.io <mailto:sean at farley.io>>
>         # Date 1444802693 25200
>         #      Tue Oct 13 23:04:53 2015 -0700
>         # Node ID 9984305b7184ceea37cb266f64f40e1021bdc10d
>         # Parent  eee993036c7c1593dbef90ae639cca5c07f10594
>         exchange: refactor push so that extensions can wrap pushop
>
>
>     I'm unsure about why you need it and if this is the right way to do
>     that.
>
>     What are you trying to achieve?
>
>     In all case I think I would prefer a clearer way to do this.
>     Something like a 'pushopsetup' function or something.
>
>
> I've also wanted this before. Use case is extensions may want to change
> attributes of pushoperation or pulloperation when they are constructed.
> It is sometimes difficult to influence these attributes from just the
> function arguments to push() and pull().
>
> I would still prefer we stop refactoring functions to facilitate
> monkeypatching and would institute something more formal, like
> https://selenic.com/pipermail/mercurial-devel/2014-September/062046.html. There
> was lukewarm reception to that idea. It was not accepted because an
> in-tree consumer (probably an extension) was needed. Perhaps we can find
> something for 3.7...

pull have a oparg argument that is passed to the pull operation. We 
should probably go that route if we want to extensibility in push operation.

(still wondering smf usecase)


-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list