Isn't this what uncommit does? I'd rather have 'uncommit --prune' or something like that.

uncommit is not able to remove multiple changeset at the same time. philosophically uncommit have a different purpose and is more single changesets centric. For example it perserve metadata (commit description etc well).

I'm a bit troubled by having prune grow an option that does more or less the same thing as uncommit. I think getting rid of csets is one operation and moving changes from a cset back into the working directory is a different operation. If indeed these are different operations, then they should remain as different commands.

I know we combine commands sometimes, rarely, like `hg pull --update`, and following this combination of two commands in one, it still seems to me like `hg uncommit --prune` is the right combination.

I don't think, on the other hand, that `hg strip --keep` is the right model to follow. I also find the idea of combining different commits all into one working directory state to be odd. Is this a frequent use case?

The point here is: "I would like to burn those commit to the ground but I want to preserve my local file" It seems reasonable to me and I've seem people doing that on a regular basis.

Bulk change: standard priority for features is 'wish'.

Bulk move open feature requests to wish priority.

Here's a "real" use case.

I start working on a large scale change.  About halfway through, I realize that I want to fold the parent of the working directory into the next commit.  But the next commit doesn't exist yet.  I *could* do hg commit/fold/uncommit, but `hg prune --keep .` is faster and easier.

Kevin, I still think `hg uncommit` should be the command that does that. You in effect want to move the changes from the last commit into the working directory. That's an uncommit!

Kevin, why don't you just use `hg amend` here?

There are a lot of things I can do here.  But hg prune --keep is the simplest thing I can do *right now* which does not require me to remember to do anything *else* later.

If I do hg amend, I'll still have to amend again once I'm satisfied with the commit.  Worse, in the meantime I can't safely push (to a publishing server)!

My point is, `hg prune --keep` doesn't seem like the right name for this option. I think `hg uncommit` describes this operation better.

Personally, I'm not attached to calling this "prune," though I can't speak for the reporter.  I just want to see the functionality included one way or another.

Perhaps hg uncommit --keep?  But then if the working directory is clean, it acts just like hg prune, so now we have the opposite problem.  Hrm.

Wow, I'm getting really confused here.  It would *not* act just like hg prune, so that's not a problem after all.

But hg prune --keep is going to break your evolution history (meta history of what changesets became what). So we are unlikely to push its usage forward to ensure `hg evolve` will work as best as possible.

`hg uncommit --all` already suggests that you might want to prune the cset, so why not add an option to make it stfu and jfdi?

Issue can be closed, checked this in mercurial 3.5.1 and prune has keep option which works fine

I still think this is the wrong fix and uncommit should be the one that changes to have --all by default and also prunes the cset. That would make it exactly the opposite of `commit`. As it is now, the opposite of `commit` is `prune --keep`, which seems all sorts of wrong.

I will soon settle this matter with an arm wrestling match against Pierre-Yves.

This is done