Of course it can deal with this: "Squash and merge" just takes the diff between the master and the branch merged with master, and applies it as a fresh patch on master (borrowing author and timestamp). Think `git merge --squash` more than the squash feature of `git rebase --interactive`. On 18 November 2016 at 07:10, Gael Varoquaux <gael.varoquaux@normalesup.org> wrote:

Can the squash and merge button of github actually deal with this? It's not obvious to me that it is even possible.

G

Sent from my phone. Please forgive brevity and mis spelling On Nov 17, 2016, at 21:02, Andreas Mueller <t3kcit@gmail.com> wrote:

...

Hi all.

I think we should change our development practices for resolving merge-conflicts from rebasing to merging. The "squash and merge" button of github gets rid of any merge commits and results in a clean history in any case.

The benefit of merging instead of rebasing is that github is able to track comments much better if you don't force-push. In particular the links in notification emails might work better when not doing force-pushes. I'm not entirely sure how the mechanism works, but I think it's worth giving it a go. When merging master it's also harder to screw up an PR entirely (I think) which would make it easier to people new to git.

Wdyt?

Andy ------------------------------

scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn

_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn

If it works, +1 on my side. I think I have never used `git merge --rebase` in the past. -- Olivier