<div dir="ltr">On Tue, Oct 2, 2012 at 10:46 PM, Matt Mackall <<a href="mailto:mpm@selenic.com">mpm@selenic.com</a>> wrote:<br>><br>> On Tue, 2012-10-02 at 22:12 +0200, Idan Kamara wrote:<br>> > On Tue, Oct 2, 2012 at 8:24 PM, Victor Garcia <<a href="mailto:bravejolie@gmail.com">bravejolie@gmail.com</a>><br>
> > wrote:<br>> > ><br>> > > # HG changeset patch<br>> > > # User victor<br>> > > # Date 1349202168 -7200<br>> > > # Node ID 6172601e7f7b3d7c8c3539e2758cfba8ab0784a4<br>> > > # Parent  e5d3b0aa48e6ab79531204f61e25ee335b306df3<br>
> > > client: add purge command<br>> ><br>> > Thanks for sending this here.<br>> ><br>> > ><br>> > > Adding the purge command to hglib. Since it's an extension, appending<br>
> > > '--config extensions.hgext.purge=' to enable it<br>> ><br>> > Like I said earlier once an extension is enabled, it lingers in<br>> > the cmdserver<br>> > process forever (since they're managed in a global variable). I guess<br>
> > that's<br>> > harmless here.<br>><br>> Not sure if I'm excited about supporting random convenience extensions<br>> in hglib.<br><div><br></div><div>I think it's useful to support extensions in general, but I agree</div>
<div>that adding it to the client class directly might not be the best</div><div>option.</div><div><br></div><div>Martin, how does JavaHg handle extensions?</div></div>