This is an archive of the discontinued Mercurial Phabricator instance.

rebase: don't use rebased node as dirstate p2 (BC)
ClosedPublic

Authored by martinvonz on Jan 11 2020, 1:47 AM.

Details

Summary

When rebasing a node, we currently use the rebased node as p2 in the
dirstate until just before we commit it (we then change to the desired
parents). This p2 is visible to the user when the rebase gets
interrupted because of merge conflicts. That can be useful to the user
as a reminder of which commit is currently being rebased, but I
believe it's incorrect for a few reasons:

  • I think the dirstate parents should be the ones that will be set when the commit is created.
  • I think having two parents means that you're merging those two commits, but when rebasing, you're generally grafting, not merging.
  • When rebasing a merge commit, we should use the two desired parents as dirstate parents (and we clearly can't have the rebased node as a third dirstate parent).
  • hg graft (and hg update --merge) sets only one parent and hg rebase should be consistent with that.

I realize that this is a somewhat large user-visible change, but I
think it's worth it because it will simplify things quite a bit.

Diff Detail

Repository
rHG Mercurial
Branch
default
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

martinvonz created this revision.Jan 11 2020, 1:47 AM
martinvonz updated this revision to Diff 19345.Jan 16 2020, 3:18 AM
martinvonz updated this revision to Diff 19541.Jan 23 2020, 4:34 PM
martinvonz updated this revision to Diff 19705.Jan 29 2020, 8:01 PM
martinvonz updated this revision to Diff 19861.Feb 3 2020, 1:08 PM
martinvonz updated this revision to Diff 19871.Feb 4 2020, 12:13 PM
martinvonz updated this revision to Diff 20097.Feb 10 2020, 7:22 PM
durin42 accepted this revision.Feb 10 2020, 9:16 PM
This revision is now accepted and ready to land.Feb 10 2020, 9:16 PM
This revision was automatically updated to reflect the committed changes.

Heads up that we ran into a fun bug that was probably caused by this patch. I think what happened was this:

  1. User ran with an older hg, which sets two dirstate parents while rebasing
  2. User ran into a merge conflict and was dropped out to their shell
  3. User upgraded hg to the new version (with this patch)
  4. User ran hg rebase --continue with the new version, which respects the dirstate parents and thus creates a merge commit (!)