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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://mail.python.org/mailman/listinfo/scikit-learn >> >> > _______________________________________________ > scikit-learn mailing list > [email protected] > https://mail.python.org/mailman/listinfo/scikit-learn > >
_______________________________________________ scikit-learn mailing list [email protected] https://mail.python.org/mailman/listinfo/scikit-learn
