> I prefer multiple commits in a single PR compared to force pushing to feature branch because it makes incremental reviewing simpler.
I agree incremental commits make reviewing simpler. However, we have a long tradition of 1 JIRA, 1 commit. This makes it easier for release managers to conduct what still falls to manual business of (1) manually verifying the branch history and JIRA fixVersions and the CHANGES.txt all align and (2) selectively reverting changes identifies as having caused issue with a release candidate. How to we weigh these competing concerns? On Tue, Apr 23, 2019 at 6:21 PM Nick Dimiduk <[email protected]> wrote: > > > I am +1 for linear commit history. > > > > Does the “squash” option give the committer enough control over the > commit > > message format and structure? I personally prefer to perform all of my > > commit rewriting locally, verify it locally, and then force-push the > > desired history to the feature branch before using the “rebase” variant > of > > the button. Maybe that process is not necessary with the “squash” option? > > > > Thanks, > > Nick > > > > On Tue, Apr 23, 2019 at 7:33 AM Sean Busbey <[email protected]> wrote: > > > > > Folks, > > > > > > Looking at history for the current master branch, we had several PRs > > > accepted over the last week where the committer used the "merge > > > commit" option. As a reminder, previous consensus was that we would > > > avoid this since it makes the history harder to follow. > > > > > > Please ensure you are selecting either "rebase commits" or "squash > > > commits" when accepting a PR. > > > > > > I have filed INFRA-18264 to disable the merge commit option. > > > > > >
