Hey. This is a continuation of the discussion we had on squashing in June: https://mail.python.org/pipermail/scikit-learn/2016-June/000121.html I thought we discussed this again after the "squash and merge" feature was introduced, but I couldn't find the thread. I think Joel, me and some others where recently using the github "squash and merge" feature, which I think is great. It removes burden from the contributors and makes for a "clean" (or fake) history. I like it because it makes cherry-picking easy and allows a pretty simple analysis of what's happening. When doing some backports, I realized that some people (including Gael) didn't use it. Is there a reason not to use squash and merge? Should we make it policy? The one case where I think we might not want it is in case there are multiple authors in a PR. Other than that, I don't really see a downside. Wdyt? Andy
That's generally my approach too. Squash and merge unless you need a record of separate authorship. Squashing helps managing cherrypicking for releases, and ensuring what's new has decent coverage. On 29 September 2016 at 00:02, Andreas Mueller <t3kcit@gmail.com> wrote:
Hey.
This is a continuation of the discussion we had on squashing in June: https://mail.python.org/pipermail/scikit-learn/2016-June/000121.html
I thought we discussed this again after the "squash and merge" feature was introduced, but I couldn't find the thread.
I think Joel, me and some others where recently using the github "squash and merge" feature, which I think is great. It removes burden from the contributors and makes for a "clean" (or fake) history. I like it because it makes cherry-picking easy and allows a pretty simple analysis of what's happening.
When doing some backports, I realized that some people (including Gael) didn't use it.
Is there a reason not to use squash and merge? Should we make it policy?
The one case where I think we might not want it is in case there are multiple authors in a PR. Other than that, I don't really see a downside.
Wdyt?
Andy _______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
On 09/28/2016 10:05 AM, Gael Varoquaux wrote:
I am not against it. When I think about why I didn't use it, it was a combination of laziness and lack of trust in git (ie I was worried of hard-to-resolve conflicts). Cool. I think we didn't run into any problems with it so far, and we have used it relatively extensively. I think it's a good default until we run into trouble. And once you use it, I think it becomes your default on github.
On 28 September 2016 at 08:18, Andreas Mueller <t3kcit@gmail.com> wrote:
On 09/28/2016 10:05 AM, Gael Varoquaux wrote:
I am not against it. When I think about why I didn't use it, it was a combination of laziness and lack of trust in git (ie I was worried of hard-to-resolve conflicts).
Cool. I think we didn't run into any problems with it so far, and we have used it relatively extensively. I think it's a good default until we run into trouble. And once you use it, I think it becomes your default on github.
With squash and merge, there shouldn't be any problems ever. Rebasing onto mastre would be the tricky part. The only disadvantage is that you loose a lot of history on large PRs.
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
On 29 September 2016 at 01:47, Nelle Varoquaux <nelle.varoquaux@gmail.com> wrote:
On 28 September 2016 at 08:18, Andreas Mueller <t3kcit@gmail.com> wrote:
On 09/28/2016 10:05 AM, Gael Varoquaux wrote:
I am not against it. When I think about why I didn't use it, it was a combination of laziness and lack of trust in git (ie I was worried of hard-to-resolve conflicts).
Cool. I think we didn't run into any problems with it so far, and we have used it relatively extensively. I think it's a good default until we run into trouble. And once you use it, I think it becomes your default on github.
With squash and merge, there shouldn't be any problems ever. Rebasing onto mastre would be the tricky part.
+1. After Github confirms that something can be merged with the click of a button, there are generally no merge issues.
The only disadvantage is that you loose a lot of history on large PRs.
participants (4)
-
Andreas Mueller -
Gael Varoquaux -
Joel Nothman -
Nelle Varoquaux