[wildfly-dev] Merge Commits

[Jason Greene]

On Sep 30, 2013, at 7:11 AM, Radoslav Husar <rhusar at redhat.com> wrote:

> On 30/09/13 12:07, Tomaž Cerar wrote:
>> One of possible ways to do it is also merge commits, aka github's "merge
>> button"
> 
> I wonder how would that help, since IIUC multiple PRs are now tested in 
> a single batch to make sure the PRs together do not cause a regression, 
> whereas each one passes the testsuite on its own. Then just push the 
> whole batch…

We would have to change the process to submit pull requests into a staging branch, and that branch once certified (all tests pass on all combination) would be pushed to the main master branch. In the event that a run fails, we would backup / redo the staging branch, and let it push again. 

> 
> Otherwise, I find merge commits messy and rarely bringing any value.

There are a number of benefits to them:

1. Easier to identify which changes belong to which PR. We have asked many times that PRs get squashed to ideally one or two commits. Very few people follow that and so it's pretty common to get 10 commits in a PR. Although it's understandable in some cases where you really really need to have multiple history points.
2. Quicker to revert a bad PR (you can just revert the merge commit and will undo everything)
3. Original Author sha-1's are preserved. This means submitters no longer have to throw away their branch to avoid conflicts of the changes they themselves wrote.
4. Github automatically closes and indicates that a PR is merged because it can track the SHA-1. Otherwise there is no effective way to know, other than guessing at the titles.
5. Easy ability to click a link from the commit history into the original pull request for those changes.
6. Ability to see commit notes in the mainline project history. (Since the sha-1 stays the same, github can render them)
7. Ability to differentiate between author's changes and conflict resolution changes during the merge
8. Recorded history of who approved/merged the PR

There are some drawbacks related to taking on additional history, and I would like to fully explore and understand them all before proposing that we switch. I have been trailing a few PRs to see how this looks.

> 
> Rado
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat