Georg Brandl writes:
I wouldn't say that. strip works well and it does so logically, once one understands the DAG. The only thing discouraged is to strip changesets once pushed to the public repo, but that holds as well for getting rid of the changesets by making a new clone without them.
Actually, neither method of "rewinding" a local repo is especially discouraged, if you know what you're doing. What you mustn't do is strip the changes in the public repo itself (or turn them into unreferencable garbage). Back in the bad old days of git, "push" often had such effects, but with modern versions of any of the dVCSes, public repos are allowed to refuse pushes that would garbage any changesets, and even if they're permitted, you need to use a --force option to push. There's nothing wrong with stripping your local repo(s), even if the stripped changes have already been pushed to the public repo. I would say it's unusual for most people to want to strip publicly available changesets, but after all, you just end up with an out-of-date repo, which is exactly what Mercurial is all about handling. Ie, it is *normal* to have an out-of-date repo locally when there are other active committers; it's just unusual to intentionally strip. But the consequences are the same. As with any out-of-date repo, you will need to merge before pushing. New users probably shouldn't do it to excess, because of the possibility of exposing yourself to a difficult merge. But the flip side is that new users probably want to update from the public repo before doing significant work for exactly the same reasons.