Gardening extensions

Bryan O'Sullivan bos at serpentine.com
Mon Feb 6 17:58:29 EST 2017


On Mon, Feb 6, 2017 at 1:45 PM, Kevin Bullock <
kbullock+mercurial at ringworld.org> wrote:

>
> Both of these are still extensions because they enable history editing. I
> recall discussions around moving these into core being predicated on evolve
> going in first. But phases are already in core, which provide one safety
> baseline for history editing...? Then again, phases don't prevent you
> losing work from a botched rebase, they only prevent you duplicating public
> changes.
>
> In principle, I'm +1 on moving them into core, but I'd like us to work out
> the safety implications for users in line with our established practice.
>

That's fair. At Facebook we now use hidden changesets to get rid of the old
commits instead of stripping, and this approach works well.

> * children - almost 10 years old, obsoleted by the children() revset
> function years ago.
>
> I'm not real enthused by the idea of a non-suppressible warning to stderr.
> I like our current approach of making the extension a dummy or shell around
> the newer core functionality. What's your reasoning for wanting a
> heavier-handed deprecation and removal cycle?
>

Well, my underlying assumption is that once these commands are in effect
gone, there's material value to deleting the rump extension code. For
example, doing so cuts startup time, which benefits everyone who enabled an
obsolete extension years ago and copypastas their hgrc around.

Consider the children extension, which has had the newer replacement
functionality documented for over a year. I'm assuming that people don't
read documentation or release notes, so if we agree that deleting the
extension makes sense, it seems preferable to nag them into using the new
thing before we delete the old.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170206/18a2f46e/attachment.html>


More information about the Mercurial-devel mailing list