jerry-skydio
commented
2 months ago Fixing the reordering problem
< A < B < C < D A A < B A < B < C A < B < C < D
D < o D < B < o D < B < C ok D < B < C < A ok
Detecting whether changes in a series got reordered
(Do this only if any base changed? might be ok to always do it) Just look through all reviews. take prev base ref name (prinfo), if that is equal to prinfo.headref for any children (recursive) then mark this review as needs workaround.
Equivalently, take prinfo.headref for every review. If that is equal to baseref for any review in relatives, mark that relative review as needing workaroud.
You can also do the equivalent with only one traversal -- just start at the leaves and maintain a set -- probably not worth extra effort given we don't store leaf info
Preventing github destruction when pushing reordered changes
- Add a dummy commit to each marked change
- Push, update github, then push again removing the dummy commit
This seems to happen when two PRs are in a relative chain and their order is swapped.
I think we can do something tricky where we push a temporary intermediate fake commit to break dependencies then push again to send the real changes. ghstack does something similar here https://github.com/ezyang/ghstack/issues/23