According to [1], there are 3 options: 1. Merge all commits 2. Squash the commits 3. Rebase the commits individually
1. is Chetan's 'git merge --no-ff feature'. 2. is my suggestion for 'fix-up' commits, with an added merge commit 3. is Chetan's 'git cherry-pick feature' if there is a single commit only So for fix-up commits there is some manual work to be done. But AFAIR we can ask the PR submitter to ammend the original commit and do a force push so we should be covered for all situations. [1]: https://help.github.com/articles/merging-a-pull-request/ On Mon, 2017-11-06 at 13:36 +0100, Carsten Ziegeler wrote: > Does this mean I need to type the commands instead of using githubs > UI? > > > Robert Munteanu wrote > > On Wed, 2017-11-01 at 10:34 +0530, Chetan Mehrotra wrote: > > > For external contributors it would be good if commit retains the > > > original author info. So I was thinking to follow approach > > > mentioned > > > in [1]. In brief use > > > > > > - `git merge --no-ff feature` for feature branches involving > > > multiple > > > commits > > > - `git cherry-pick feature` for simple bug fixes > > > > +1 from me. > > > > Also it would be important IMO to ensure that 'fix-up' commits get > > squashed. > > > > Assume we have a PR with a simple commit that adds some Javadoc to > > a > > method. That commit introduces a typo, so another commit is added > > to > > the PR. I think the PR should be included as a single commit, not > > as > > two. > > > > Robert > >
