[mrb]

(I know Mercurial very well. I evaluated 5 or 6 distributed VCS tools and decided to migrate my employer's repository from CVS to Mercurial in 2008: 2GB of history, 150k files, 20k changesets, dozens of developers.)

I don't understand the poster's insistence about wanting to perform an operation similar to git stash in Mercurial "without creating a commit". Creating an ephemeral commit is precisely the perfect solution in Mercurial! Do it, then all regular Mercurial commands (log, diff, etc) will work to manage it. To get rid of the temporary commit later, simply "hg strip" it. It will remove the changeset (and all its children, if any) from the history (a backup will be made in .hg/strip-backup). hg strip is part of the built-in mq extension.

Also, a simple solution to the poster's last complain (re-doing a commit while keeping history of the original commit) is as follow: let's say you are at revision A. You commit B. You realize you screwed up. So you go back to A: hg update A. Then you revert your working directory to the state of B: hg revert --all --no-backup -r B. Then you make the changes you forgot, and commit again: hg commit.

[gcp]

I don't understand the poster's insistence about wanting to perform an operation similar to git stash in Mercurial "without creating a commit".

Having it as a real commit is an issue when you want to pull upstream for example. My solution would be hg qnew stashname, but I already ranted about the limitations of MQ in another thread here.

[mrb]

Why is it an issue when you want to pull upstream? If you do it, the temp commit will live aside from all the csets pulled from upstream. If you want to resume work on it later, then just update to it. If you want to resume work on it while effectively "merging" its changes with recent upstream changes, then simply rebase the temp commit: hg rebase -s tempcommit -d new-head-pulled-from-upstream. (rebase is a built-in extension.) That's the workflow policy I implemented and it works well. It is also easy to keep track of temp commits: running hg incoming/outgoing will show which changesets are present/absent in one repo compared to whatever other repo you use as a reference.

[lloeki]

Will this preserve the original B? Is it easy to throw away B' and go back to B? (honest question, I know hg only superficially)

The two hg commands you mentioned are summed up as one with git: git reset --soft HEAD^. Then if you commit B' but ever want to go back to B, you could do git reset --hard HEAD@{2}

[mrb]

Absolutely, it would preserve the original B.

You can easily switch your working directory to one of them: hg update B or B'

You can easily throw away the one you don't want to keep: hg strip B or B'