3 ms·

Last time I had to use Hg on a client project, disposable topic branches didn't seem to be something really supported. Broke our usual workflow and made a small

• ptx 4y ago
  Git-style branches are called bookmarks[1] in Mercurial and "rebase -i" is called histedit[2]. It works pretty much the same. [1] https://www.mercurial-scm.org/wiki/Bookmarks https://www.mercurial-scm.org/wiki/Bookmarks [2] https://www.mercurial-scm.org/wiki/HisteditExtension https://www.mercurial-scm.org/wiki/HisteditExtension
  • 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 ago
      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.
    • aayjaychan 4y ago
      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.
• 8n4vidtmkvmk 4y ago
  supposed to use bookmarks in hg but i used named branches anyway and that worked perfectly fine too