Hi, Isn't there a benefit to 'squash and merge' since it can keep some work-in-progress commits from ending up in the main branch history? Just curious if there are other considerations since both squash-and-merge and rebase-and-merge seem pretty similar (both use fast-forward-merging so no merge commit).
Thanks, Peter -----Original Message----- From: James Peach [mailto:jpe...@apache.org] Sent: Monday, September 26, 2016 2:37 PM To: dev@trafficserver.apache.org Subject: Re: github rebase merging > On Sep 26, 2016, at 12:24 PM, Leif Hedstrom <zw...@apache.org> wrote: > >> >> On Sep 26, 2016, at 12:34 PM, Bryan Call <bc...@apache.org> wrote: >> >> +1 - Glad to see they are doing this. >> >> -Bryan >> >> >> >> >>> On Sep 26, 2016, at 11:27 AM, James Peach <jpe...@apache.org> wrote: >>> >>> Hi all, >>> >>> Github just released a new "rebase merging" feature, which makes merging >>> PRs as clean as doing the merge by hand. See >>> https://github.com/blog/2243-rebase-and-merge-pull-requests. >>> >>> I'd like to propose that we always "rebase merge" PRs. There may be >>> occasions where we would not do this, but I expect they are rare. >>> >>> Here are the merge button options that can be toggled: >>> >>> * Allow merge commits >>> Add all commits from the head branch to the base branch with a merge >>> commit. >>> >>> * Allow squash merging >>> Combine all commits from the head branch into a single commit in the >>> base branch. >>> >>> * Allow rebase merging >>> Add all commits from the head branch onto the base branch individually. > > > +1 as well. It’s worth asking Infra if they can disable the other options, > but I have no idea if they can. https://issues.apache.org/jira/browse/INFRA-12658
