github's "merge" button works by creating a "merge commit" which is the commit that would result by merging a PR into master.
Murdock currently rebases a PR before compile-testing it. It inherited that (wrongly?) from the Travis scripts.
Now this somehow feels inconsistent, as a different configuration than merged is tested. I think testing the merge commit would ideally lead to a tested master HEAD after merge.
On the other hand, if we'd test the merge commit, it is tested against the master HEAD at the time of committing to the PR branch, which also leads to a differrent merge configuration if another PR gets merged in the meantime.
Opinions? What was the original intention of testing for "rebaseability"? Isn't that implicitly checked by github's merge test?