My gut feel would be just to squash and merge, it usually works quite well.
Is there any chance that someone might want to cherry-pick, revert or rebase any portions of the PR? If so what I try and is to provide atomic commits the bring small individual pieces of value to the codebase. This often means at the end of the PR I'd do some git hygiene, get rework my commits and then force push. I try to ensure that I also leave a backup branch in GitHub that contains my original git history. If you have an atomic chain of commits then it might make more sense to rebase and merge. On Wed, Sep 26, 2018, 3:41 PM Carin Meier <carinme...@gmail.com> wrote: > The Import Julia binding PR ,( > https://github.com/apache/incubator-mxnet/pull/10149), is getting very > close to being merged. Because of the large number of commits there was a > suggestion not to use the usual "Squash and Merge". The only option would > be "Rebase and Merge" since merging with a merge commit is not enabled for > the project. > > *Squash and Merge* - The commits from this branch will be combined into one > commit in the base branch (With all the commit messages combined) > > *Rebase and Merge* - The commits from this branch will be rebased and added > to the base branch > > The PR is over 250+ commits (Github won't show all of them) > > Thoughts about how we should handle the merge? > > Thanks, > Carin >
