Unexpected order of hunks in patch comparison
Sabrina reported that the hunks in patch comparison sometimes have a weird order.
The problem is visible if the right side has hunks that are not on the left side and offsets on the left and right side are different. For example:
The upstream patch:
@@ -100,7 +100,7 @@
hunk one
@@ -200,7 +200,7 @@
hunk two
@@ -300,7 +300,7 @@
hunk three
@@ -400,7 +400,7 @@
hunk four
The downstream patch:
@@ -100,7 +100,7 @@
hunk one
@@ -350,7 +350,7 @@
hunk two
The comparison will be shown as:
@@ -100,7 +100,7 @@ | @@ -100,7 +100,7 @@
hunk one | hunk one
| @@ -300,7 +300,7 @@
| hunk three
@@ -350,7 +350,7 @@ | @@ -200,7 +200,7 @@
hunk two | hunk two
| @@ -400,7 +400,7 @@
| hunk four
While more logical would be:
@@ -100,7 +100,7 @@ | @@ -100,7 +100,7 @@
hunk one | hunk one
@@ -350,7 +350,7 @@ | @@ -200,7 +200,7 @@
hunk two | hunk two
| @@ -300,7 +300,7 @@
| hunk three
| @@ -400,7 +400,7 @@
| hunk four
The problem is in the sort of hunks. For the __lt__
, __le__
and __eq__
comparison via patch.ComparedProxy, we take the left hunk header, and if it is not present, the right hunk header. We're thus sorting (100, 300, 350, 400).
Changing this to always use right side hunk header will not work, though, since it will show exactly the same problem if there are added hunks on the left side instead. It seems can't just use sort
here but do something more clever that takes into account relative positions of hunks that are only on a single side.