NO-JIRA enable squash+merge on GitHub
Currently we usually ask PR authors to squash their commits before we merge. However, it's possible for GitHub to automate this which would speed up the merging process and reduce busy-work for PR authors.
Furthermore, incremental commits throughout the review process can be useful as previous comments are preserved in context and changes are more clear.
LGTM, I'm just not sure if squash_commit_message should be
PR_TITLE_AND_DESCbecause I read a bad feedback on it, see https://issues.apache.org/jira/browse/IGNITE-24959
I have similar concerns here on the quality of the commit messages from this change.
I update the PR to use PR_TITLE instead of PR_TITLE_AND_DESC.
will the Squash & Merge also perform a rebase?
I hate merge commits... as they get difficult to track for no reason... (for our workflow at least)
will the Squash & Merge also perform a rebase?
I don't believe so.
See more info at https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github.
I would not do it then... I really hate the spaghetti merge commits can make on the main branch.
If you did it intentionally at least you manage the spaghetti and know the consequences... doing it auto-magically it creates more mess than good IMO.
I tested the Squash and merge on my test repo and it didn't create a merge commit in the following cases:
- PR branch with common ancestor equal to main HEAD
- PR branch with common ancestor different from the main HEAD
- PR branch with multiple commits and common ancestor different from the main HEAD
See https://github.com/brusdev/test/commits/main
As noted in Dom's experiments and in the link I cited previously, squashing shouldn't create a merge commit. Here's what happens:
My understanding was that if D and E were on an ancestor it would be merged as an ancestor
But if the squash and commit would bring it to the TIP of the branch.. than I'm +1000 on this.