[scikit-learn] Development workflow proposal: merge master instead of rebasing

[Joel Nothman]

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 at 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 at 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 at python.org
>> https://mail.python.org/mailman/listinfo/scikit-learn
>>
>>
> _______________________________________________
> scikit-learn mailing list
> scikit-learn at python.org
> https://mail.python.org/mailman/listinfo/scikit-learn
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-learn/attachments/20161118/a0a9635e/attachment.html>