4 ms·
> "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 th
by orra 4y ago
> "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.
- thfuran 4y agoUnless 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.
- aayjaychan 4y agoNo 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.