[Pandas-dev] Thoughts on adopting a 1-PR-1-commit policy?

[Wes McKinney]

Copying the mailing list. Indeed makes rebasing unnecessary if there
are no cherry-pick conflicts.

On Sat, Jan 16, 2016 at 3:34 PM, Tom Augspurger
<tom.augspurger88 at gmail.com> wrote:
> Rebasing can be tough for new contributors, so for that alone I'd say let's try it.
>
> -Tom
>
>> On Jan 16, 2016, at 5:20 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
>>
>> I've grown very fond of the PR cherry-picking style used in many
>> Apache projects.
>>
>> Here's an example of a very large commit to Apache Spark that was
>> performed in this fashion:
>>
>> https://github.com/apache/spark/commit/2fe0a1aaeebbf7f60bd4130847d738c29f1e3d53#diff-e1e1d3d40573127e9ee0480caf1283d6
>>
>> If you compare pandas's commit history with a project like this,
>> you'll see it is much easier to follow because there is one commit for
>> each patch to the project, rather than a merge commit plus 1 or more
>> merged commits (depending on whether the person merging the PR did an
>> interactive rebase).
>>
>> The script to do this is not too complex, and is even less complex for
>> pandas because we do not use JIRA:
>>
>> https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py
>>
>> I've been using a pared down version of the script in Ibis:
>>
>> https://github.com/cloudera/ibis/blob/master/dev/merge-pr.py
>>
>> Here is an example of what a merge commit with multiple subcommits
>> looks like using this tool:
>>
>> https://github.com/cloudera/ibis/commit/eafabe060dcaaea0a6076342eaa374929b91cf47
>>
>> It's pretty easy to use: run the script and enter the PR # you are
>> merging. It automatically squashes and closes the merged PR.
>>
>> Let me know if this is something that would interest the team. I know
>> there are varying opinions on the GitHub Green Button =)
>>
>> - Wes
>> _______________________________________________
>> Pandas-dev mailing list
>> Pandas-dev at python.org
>> https://mail.python.org/mailman/listinfo/pandas-dev