The rebase went wrong.
Your branch is now a mess of conflicts, dangling commits, and half-finished merges. You stare at the history, feeling the weight of every change. You know what you want: a clean, linear sequence of commits ready to ship. You’ve done it a hundred times in Git. But now you’re in Mercurial, and the commands in your muscle memory don’t work the way you expect.
Rebasing in Git and Mercurial are not the same. Both version control systems can rewrite commit history, but they do it through different models. In Git, git rebase moves commits from one base to another, creating a neat, single line of history. It’s common before merging a feature branch into main. In Mercurial, rebase is an extension that pulls changesets onto a new parent revision. It works differently at the edges. Mercurial is changeset-based, not snapshot-based, and its DAG behaves in a way that alters the meaning of certain rebases you’ve taken for granted in Git.
The first key difference is commit identity. In Git, rebasing creates new commit hashes because it builds new snapshots. In Mercurial, rebasing also changes changeset IDs, but because of its metadata handling, conflicts and ancestry resolutions can feel unfamiliar. The second difference is tool behavior — Git’s rebase interface has built-in options like --interactive, --skip, and --abort that are named differently or handled differently in Mercurial. Mercurial’s hg rebase has its own syntax and flags, and understanding them is critical to avoid dangling heads.
When working across these systems, you can’t just port your Git habits into Mercurial. The mental model must shift. Git encourages frequent interactive rebases to clean up history before pushing. Mercurial historically prioritized immutable history on shared repos, making certain rebases more restricted unless the phase of the changeset is draft. That means the same workflow you perfected in Git might require rethinking in Mercurial — not because Mercurial is less capable, but because its safety rules and history model are different.
If you need to move a branch’s base in Mercurial, run hg rebase -s REV -d DEST where -s is the source revision and -d is the destination. Understand that this will alter changeset IDs and may need a force push depending on repo settings. If you’re switching between Git and Mercurial frequently, maintaining mastery in both requires reading their histories not just as commands, but as the underlying graph transformations taking place.
The reason to care about these differences is simple: rebase is history surgery. Do it wrong, and you break the build or lose work. Do it right, and your team’s repository remains clean, clear, and easy to navigate. The cleaner the history, the faster the onboarding, debugging, and release cycles.
If you want to experiment with both Git and Mercurial workflows, test them in an isolated environment without risking your production repositories. hoop.dev makes it possible to spin up environments fast, see the results of rebases instantly, and share them with your team without setup friction. You can watch a Git rebase or a Mercurial rebase play out in minutes, side by side. Try it now, and see the difference live.