Bug 239752
| Summary: | Support merging pull requests containing multiple commits | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Elliott Williams <emw> |
| Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 239082 | ||
Elliott Williams
Currently, it seems like we require PR branches to be squashed before merging. I think we should encourage contributors to write PRs with multiple commits by lifting this restriction and instead teaching Merge-Queue to do the squashing. I would expect it to use the PR description to write the squashed commit.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/92648043>
Elliott Williams
Real world example of where a workflow like this is needed: I'm relanding a change along with a fix. I think it's most logical, both for history and my reviewers, to land two commits: one is the automated `git revert` commit which undoes the revert, and the other applies fixes.
Currently, I'm forced to squash them together. As a result, the merged commit doesn't make it clear what was changed.