Merge ~cjwatson/launchpad:faster-detect-merges into launchpad:master
Status: | Merged |
---|---|
Approved by: | Colin Watson |
Approved revision: | f08d401db953497711354c4de47a5293261c36a6 |
Merge reported by: | Otto Co-Pilot |
Merged at revision: | not available |
Proposed branch: | ~cjwatson/launchpad:faster-detect-merges |
Merge into: | launchpad:master |
Diff against target: |
196 lines (+61/-17) 7 files modified
lib/lp/code/interfaces/githosting.py (+3/-1) lib/lp/code/interfaces/gitrepository.py (+4/-1) lib/lp/code/model/githosting.py (+14/-4) lib/lp/code/model/gitrepository.py (+2/-1) lib/lp/code/model/tests/test_githosting.py (+13/-1) lib/lp/code/model/tests/test_gitrepository.py (+17/-8) lib/lp/code/subscribers/git.py (+8/-1) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Simone Pelosi | Approve | ||
Review via email: mp+449451@code.launchpad.net |
Commit message
Speed up merge detection in repositories with deep history
Description of the change
Merge detection can be very slow for repositories with deep history, because as currently defined it has to walk through the whole ancestry of a given target commit looking for "mainline" (first parent only) commits that introduce a merge of any of the given source commits. In particular, this often times out for Linux kernel repositories.
However, we can do much better. Merge proposals are normally only created in Launchpad once the target branch has been scanned, and we can reasonably assume that when a merge proposal is created it won't yet have been merged. This means that Launchpad can tell turnip's `detect-merges` API to stop walking through history whenever it encounters the commit that it had previously scanned on the target branch, and then we only have to look through the changes introduced by a push rather than the entire history of the branch. This should be much less likely to time out.
(See also https:/
LGTM!