On Sat, 25 Nov 2017 21:46:55 -0500, Matt Harbison wrote: > > On Nov 25, 2017, at 9:34 PM, Yuya Nishihara <y...@tcha.org> wrote: > >> On Thu, 23 Nov 2017 14:29:25 -0500, Matt Harbison wrote: > >> # HG changeset patch > >> # User Matt Harbison <matt_harbi...@yahoo.com> > >> # Date 1511417702 18000 > >> # Thu Nov 23 01:15:02 2017 -0500 > >> # Branch stable > >> # Node ID 939e30e7ca1c925e5209f03805cd7f18583f2550 > >> # Parent 02845f7441aff30bc01975a5881cabfa922c12d4 > >> largefiles: load the convert extension as needed to register config items > > > > Perhaps the easiest way around is to move all configitems into core as we > > did > > for the share extension. > > Yes, that was the hash I referenced. But like I said, the share > functionality is actually implemented in the core, and these aren’t, so it > seems a bit odd. > > The bigger issue though is I need to have the convert extension load, in > order for it to be wrapped by the lfs extension. (The basic flow is to wrap > convert, but if isn’t loaded, wrap largefiles. Then when largefiles loads, > wrap convert in an lfconvert override.) It would be weird for the user to > not need to load convert when using lfconvert, unless also using lfs. I can > submit that series as an RFC too (or put it on bitbucket) if you’d like to > see what I mean.
I think some logic of the convert extension can be moved to core as well, so the largefiles will no longer need to wrap extension functions. I don't know if that will work for lfs, though. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
