By historical consensus, hg --config extensions.mq strip is sufficient.

> debugtruncate in core.

+1 from me too.

<mpm> I would be less troubled by having, say, debugtruncate in core.

For many use-cases (especially the cases I had) this is enough, so +1 from me

Strip is still problematic for the core.

The append-only property of Mercurial files is a safety net against future
software bugs or hardware failure corrupting historic data, something that
becomes increasingly likely on timescales of decades.

Mq breaks this rule rather dramatically. That's fine for short-lived branches on
laptops where the damage is well-contained but not for central archives.
Therefore the strip command should be explicitly part of the mq functionality
(possibly with a 'q' prefix).

not really renaming, it should still be accessible as strip.
But currently the only way to hide a command from help is to name it debugfoo,
so the command table entry would be "debugstrip|strip".

I'm not generally in favour of educating users by deliberately making certain 
operations more difficult, but I guess there's no harm in just making the command 
harder to find. Still, I think it's got more general utility than your typical 
debug command, and am mildly against renaming it to debugstrip. But I do think it 
belongs in core.

the problem is not the destructiveness of 'hg strip' (we save a backup bundle
now), but the workflow implications. Getting used to immutable history is an
important thing when working with Mercurial, know the rules before breaking
them, and such.

the revert command is equally descructive (though the recently added --all help
ease my mine a little), so trying to hide 'strip' doesn't make a lot of sense.

+1 to debugstrip.

Added asak (alexis) to the nosy, too.

Reopening myself after thinking about this a little bit more.
Strip is in the mq extension for historic reasons, I think we can ignore this
when talking about usability.

If strip would be in hg core, one danger would be that a user will learn this
command too early, but this safety net is already disabled by distributions or
admins enabling mq by default.

If strip would be in hg core, but be named debugstrip (with strip as alias) it
will be hidden, so the newbie user will not be confused by it or adapt his
working style to having this command available.

If we get a better help system in the future, strip could be listed in the
advanced commands section or sth. like that.

Are there other reasons for not having strip in hg core?

Enabling the mq extension is easy and will provide the strip command.
The annoying help output is a different problem addressed in issue197

Please reopen a separate issue if you think mq should add less help entries by
default, as we already have 'hg help mq'.

Clone -r doesn't support hardlinks. I don't use mq, but just want the strip
commmand. The extension adds the [long list of] mq commands to the default
command list, which I find rather annoying (IMO, no extension commands should
invite themself to the default list)

On Fri, 2006-03-03 at 17:10 -0800, TK Soh wrote:

> Why is the status set to 'resolved'? mq is added to mainline only as an extention. The original
> suggestion was to make strip a standard command.

We already have clone -r and pull -r for that.  If you need actual
strip, just put mq in your extensions line.

	<b

--- Bryan O'Sullivan <mercurial-bugs@selenic.com> wrote:
> 
> Bryan O'Sullivan <bos@serpentine.com> added the comment:
> 
> mq is in mainline now.
> 
> ----------
> status: chatting -> resolved

Why is the status set to 'resolved'? mq is added to mainline only as an extention. The original
suggestion was to make strip a standard command.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

mq is in mainline now.

+1

Move mq's strip command to Mercurial.