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