Murdock and merge commits

Development archive
1

Hey all,

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?

Kaspar

2

Hi Kaspar,

What was the original intention of testing for “rebaseability”? Isn’t that implicitly checked by github’s merge test?

It’s not the rebaseability that is checked, but to help against the problem you cited: including changes from master. On the other hand, I would also say that merging instead of rebasing to master would be the more correct way to go.

Cheers, Martine

3

Hey,

4

Yes