Stanislau Hlebik ae737fe22c mononoke: change fetch_bonsai_range semantics ... Summary: Previously fetch_bonsai_range returned all commits between `ancestor` and `descendant`, but `ancestor` was included. This is usually not what we want and it might be surprising and can lead to subtle bugs. As an example, next commit in the stack might have failed pushrebases when it shouldn't do that. This diff changes the semantic of the function to exclude an ancestor. This function was used for 2 use cases: 1) Find changed files. find_rebased_set function was manually removing the ancestor anyway, so there's no change in behaviour 2) To check that there are no case conflicts. Previously we were checking the case conflicts with ancestor included, but that wasn't necessary. To prove that let's go over the two possible situation: i) This is a first iteration of the pushrebase ``` CB SB | | ... ... CA SA | / root ``` in that case files introduced by root commit will be used to check if we have case conflicts or not. But this is not necessary, because pushrebase assumption is that CA::CB should not introduce any new case conflicts. Besides, even if they added a case conflict then checking with just the files that were changed by root commit is not enough to verify that. Similar logic goes to SA::SB commits. Checking if root has any conflicts with SA::SB commits doesn't make sense. ii) This is not the first iteration of the pushrebase ``` CB SB | | ... ... CA SA | O <- latest pushrebase attempt ... <- we rebased over these commits on the previous attempts | / root ``` In this case it's even easier. Commit O was verified on the previous iteration, so no need to add it here again. Reviewed By: aslpavel Differential Revision: D24110710 fbshipit-source-id: 90dff253cba0013e9d5e401474132a152d473cae		2020-10-05 12:49:04 -07:00
..
src	mononoke: change fetch_bonsai_range semantics	2020-10-05 12:49:04 -07:00
Cargo.toml	bookmarks: extract BundleReplayData from BookmarkUpdateReason	2020-07-10 04:50:24 -07:00