Hacker News Reader

> "rebase -i" is called histedit. It works pretty much the same.

Is there a reflog, though? When I mess up a git rebase, I have confidence I can always undo the rebase and try again.

When I used Mercurial, admittedly over five years ago, there wasn't a reflog. Sure, you'd get some .bak files when editing the history, but that's nowhere near as safe.

View on HN

No reflog, but there is the obslog, which stores obsolescence history of individual revisions. Better yet, the obslog is distributed during pull / push. Because Mercurial knows precisely which commit is replaced by which commit, it can automatically resolve a lot of conflicts that result from history editing.

Have a branch-a that depends on branch-b that depends on branch-c that upstream just rebased and squashed some of its commits? More often than not `hg pull && hg evolve` is all you need to do to synchronise everything. This makes stacked PRs much easier to manage.

Unless you explicitly set config otherwise, any time you rebase / strip / histedit, a copy of the original commit(s) gets saved and can be restored with a single command.

Reply on news.ycombinator.com