|
|
|
|
|
by agentgt
3588 days ago
|
|
I too admit that I'm a huge Hg fan (will not switch the company code to git) but I also admit history rewriting is a damn worthy feature. At the very minimum I think we can agree that safe rebasing is better than a plethora of merges that really serve no purpose other than to clutter history. The more distributed and diverse/disparate your team is the more I think history editing + cheap branching is worthwhile (but on the opposite end I think Hg consistency is better for corp). One of my greatest challenges in using/understanding Git was(/is still) the reflog. I know the reflog isn't that complicated but there isn't anything really analogous in other SCM (of my limited knowledge of perforce, svn, hg, git). Also for some reason the presentation of the reflog UI wise is intimidating. Reflog is nice gem for git particularly since the builtin Mercurial rollback (I wish they would just remove that command) is fairly awful (use histedit or rebase instead). That being said Mercurials new changeset evolution experimental stuff looks really promising [1]. That being said if you are looking to undo in hg like this article talks about you have to look at the hg unbundle backupfile
Unbundle is a pretty nasty command compared to the reflog commands but on the other it is just restoring from some backup file. I'm not too sure how you can transfer reflogs around.[1]: https://www.mercurial-scm.org/wiki/ChangesetEvolution |
|
That being said, I've been using changeset evolution for over a year and it is awesome. Instead of creating a bundle your commits are just hidden. You can run any of your hg log commands with --hidden and it shows you those hidden commits. You can see exactly how your rebase removed (hid) some old commits and created new ones. It's very easy.