Gardening extensions

[Sean Farley]

Augie Fackler <raf at durin42.com> writes:

> 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

Though, I kind of like the idea of removing old cruft. (shrug)