Gardening extensions

Augie Fackler raf at durin42.com
Mon Feb 6 18:40:01 EST 2017


On Mon, Feb 06, 2017 at 02:58:29PM -0800, Bryan O'Sullivan wrote:
> 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.

The way we've dealt with this in the past is silently force-disabling
the old config entry, namely this list:

https://www.mercurial-scm.org/repo/hg/file/tip/mercurial/extensions.py#l29


> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list