This is an archive of the discontinued Mercurial Phabricator instance.

Differential D8115

rebase: show bug when rebasing merge with obsoleted revs on both sides
AbandonedPublic

Authored by durin42 on Feb 13 2020, 4:00 PM.

Details

Reviewers
None
Group Reviewers
hg-reviewers
Summary

By inspection, the rebase should be fine: "just" omit 8 and 10 from
the rebase. This is a simplified case of something we're seeing at
Google.

DO NOT ACCEPT: this is being shared to try and get help figuring out
how to resolve the issue.

Diff Detail

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

Event Timeline

durin42 created this revision.Feb 13 2020, 4:00 PM
martinvonz added a subscriber: martinvonz.Feb 25 2020, 6:30 PM

We already have tests for this (grepping for "unwanted changes" in tests/ should be enough to find them).

It's not easy to omit revisions 8 and 10 from the rebase. The key is to realize that rebase is done by repeated grafting of diffs and that the diffs are always between two commits. We can therefore rebase revisions 9 and 11 without a problem (we take the diff from revisions 8 and 10, respectively). But when rebasing the merge commit, which diff do we graft? If we use 9 as base (i.e. we try to graft the diff between 9 and 12), we'll get unwanted changes from commit 10. Conversely, if we use 11 as base, we'll get unwanted changes from commit 8.

I have been thinking a bit about how to solve it by doing the rebase in smaller steps, but it's pretty complicated and maybe I should write it down in a plan page instead.

marmoute added a subscriber: marmoute.Mar 19 2020, 8:16 PM
In D8115#121345, @martinvonz wrote:

We already have tests for this (grepping for "unwanted changes" in tests/ should be enough to find them).
It's not easy to omit revisions 8 and 10 from the rebase. The key is to realize that rebase is done by repeated grafting of diffs and that the diffs are always between two commits. We can therefore rebase revisions 9 and 11 without a problem (we take the diff from revisions 8 and 10, respectively). But when rebasing the merge commit, which diff do we graft? If we use 9 as base (i.e. we try to graft the diff between 9 and 12), we'll get unwanted changes from commit 10. Conversely, if we use 11 as base, we'll get unwanted changes from commit 8.
I have been thinking a bit about how to solve it by doing the rebase in smaller steps, but it's pretty complicated and maybe I should write it down in a plan page instead.

looks like a legitimate need for 5 ways merge.

@durin42 can we get this revision out of yadda? It is not ready to land and we won't have a solution soon™

durin42 abandoned this revision.Mar 20 2020, 11:53 AM

Revision Contents
Changeset List

PathPackages
Mtests/test-rebase-obsolete.t (76 lines)

Diff 20198

tests/test-rebase-obsolete.t

| * 3: 67a385d4e6f2 'D' bookmarks: Z | * 3: 67a385d4e6f2 'D' bookmarks: Z
| | | |
| x 2: 49cb3485fa0c 'C' bookmarks: | x 2: 49cb3485fa0c 'C' bookmarks:
| | | |
| x 1: 6c81ed0049f8 'B' bookmarks: | x 1: 6c81ed0049f8 'B' bookmarks:
|/ |/
o 0: 1994f17a630e 'A' bookmarks: o 0: 1994f17a630e 'A' bookmarks:
Rebase a merge where some of the ancestors on both sides of the merge
have successors that have linearized.
$ echo alpha > alpha
$ hg ci -Am alpha alpha
created new head
$ echo beta > beta
$ hg ci -Am beta beta
$ hg co 5
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
$ echo gamma > gamma
$ hg ci -Am gamma gamma
created new head
$ echo delta > delta
$ hg ci -Am delta delta
$ hg merge 9
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg ci -m merge
$ hg co 7
2 files updated, 0 files merged, 4 files removed, 0 files unresolved
$ echo alphaprime > alpha
$ hg ci -Am alphaprime alpha
$ echo gammaprime > gamma
$ hg ci -Am gammaprime gamma
$ hg debugobsolete `hg log -r 8 -T'{node}'` `hg log -r 13 -T'{node}'`
1 new obsolescence markers
obsoleted 1 changesets
2 new orphan changesets
$ hg debugobsolete `hg log -r 10 -T'{node}'` `hg log -r 14 -T'{node}'`
1 new obsolescence markers
obsoleted 1 changesets
1 new orphan changesets
$ hg log -GT "{rev}: {node|short} '{desc}'"
@ 14: c87966a2bac9 'gammaprime'
|
o 13: 6405e0193644 'alphaprime'
|
| * 12: 608f8c33b2dd 'merge'
| |\
| | * 11: 8415a35bb872 'delta'
| | |
| | x 10: 4219fc7517e7 'gamma'
| | |
| * | 9: 6cf04930d1a4 'beta'
| | |
| x | 8: a71f025d4776 'alpha'
| |/
o | 7: 9c86c650b686 'C'
| |
o | 6: 9b87b54e5fd8 'B'
|/
o 5: 39adf30bc1be 'conflict with d'
|
o 4: 9c1e55f411b6 'E'
|
| * 3: 67a385d4e6f2 'D'
| |
| x 2: 49cb3485fa0c 'C'
| |
| x 1: 6c81ed0049f8 'B'
|/
o 0: 1994f17a630e 'A'
$ hg co 12
4 files updated, 0 files merged, 2 files removed, 0 files unresolved
Sadness: the rebase doesn't work, because it's confused by the
linearization that's taken place. :(
$ hg rebase -d 14
note: not rebasing 8:a71f025d4776 "alpha", already in destination as 13:6405e0193644 "alphaprime"
rebasing 9:6cf04930d1a4 "beta"
note: not rebasing 10:4219fc7517e7 "gamma", already in destination as 14:c87966a2bac9 "gammaprime" (tip)
rebasing 11:8415a35bb872 "delta"
rebasing 12:608f8c33b2dd "merge"
abort: rebasing 12:608f8c33b2dd will include unwanted changes from 8:a71f025d4776 or 10:4219fc7517e7
[255]