Thu, 27 Dec 2018 23:46:35 -0500 exthelper: simplify the ability to register filesets
Matt Harbison <matt_harbison@yahoo.com> [Thu, 27 Dec 2018 23:46:35 -0500] rev 4330
exthelper: simplify the ability to register filesets Same mechanism as revsets earlier in this series.
Thu, 27 Dec 2018 21:55:22 -0500 exthelper: simplify the ability to register templates
Matt Harbison <matt_harbison@yahoo.com> [Thu, 27 Dec 2018 21:55:22 -0500] rev 4329
exthelper: simplify the ability to register templates Same mechanism as revsets earlier in this series.
Thu, 27 Dec 2018 21:26:17 -0500 exthelper: simplify the ability to register revsets
Matt Harbison <matt_harbison@yahoo.com> [Thu, 27 Dec 2018 21:26:17 -0500] rev 4328
exthelper: simplify the ability to register revsets I think this is what Yuya and Boris agreed on.[1] This happens *after* the extsetup phase now (and after the _aftercallback notifications). But this is trivial, mergeable between exthelper instances, and doesn't need to have the extension name supplied when registering. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-December/125888.html
Sun, 23 Dec 2018 21:54:56 -0500 exthelper: support the option argument when registering a command
Matt Harbison <matt_harbison@yahoo.com> [Sun, 23 Dec 2018 21:54:56 -0500] rev 4327
exthelper: support the option argument when registering a command Largefiles uses this 5th argument with push and pull, so this will be tested in the next commit. I assume the reason for unrolling and reforming the tuple in each finalxxxsetup() is to validate that something proper was passed in when registering. But it's better to explode when decorating than during the delayed actual registration.
(0) -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 tip