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

Wes McKinney wesmckinn at gmail.com
Sun Jan 17 14:14:52 EST 2016


It only preserves the primary author, so there are some edge cases
where GitHub metadata would get lost.

On Sun, Jan 17, 2016 at 11:04 AM, Stephan Hoyer <shoyer at gmail.com> wrote:
> Does it preserve credit for all the authors on a PR (beyond the first), even
> if they don't even end up as the author on squashed commit? That would
> surprise me. I do agree this is a bit of an edge case, though it does
> include big merges like the one in your original email.
>
>
>
> On Sun, Jan 17, 2016 at 10:59 AM, Wes McKinney <wesmckinn at gmail.com> wrote:
>>
>> I just made my first patch to Parquet, which was committed with this
>> method, and you can see it here
>>
>> https://github.com/apache/parquet-cpp/graphs/contributors
>>
>> On Sun, Jan 17, 2016 at 10:56 AM, Jeff Reback <jeffreback at gmail.com>
>> wrote:
>> > if this preserves the individual authors commits (and it appears that
>> > way),
>> > then I am all for a single commit,
>> > even for large patches.
>> >
>> >
>> >
>> > On Sun, Jan 17, 2016 at 1:48 PM, Wes McKinney <wesmckinn at gmail.com>
>> > wrote:
>> >>
>> >> On Sun, Jan 17, 2016 at 10:46 AM, Stephan Hoyer <shoyer at gmail.com>
>> >> wrote:
>> >> > On Sunday, Jan 17, 2016 at 10:40 AM, Wes McKinney
>> >> > <wesmckinn at gmail.com>,
>> >> > wrote:
>> >> >>
>> >> >> The patch tool does not occlude the patch author identity on GitHub
>> >> >> (i.e. the patches will show up on the user profile just the same).
>> >> >
>> >> > Yes, but not on the "contributors" page for the github project
>> >> > itself.
>> >>
>> >> No, this is not true. See
>> >> https://github.com/apache/spark/graphs/contributors
>> >>
>> >> > That said, I agree that atomic commits are useful for large projects.
>> >> > This
>> >> > is part of why we encourage/require squashing. I'm not entirely sure
>> >> > that
>> >> > pandas has enough synchronous developments that this is necessary.
>> >> > If this helps maintaince branches, it would certainly be a win -- we
>> >> > haven't
>> >> > been very good about maintaining bug fix only branches, which would a
>> >> > healthy thing to do for a mature project.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> _______________________________________________
>> >> Pandas-dev mailing list
>> >> Pandas-dev at python.org
>> >> https://mail.python.org/mailman/listinfo/pandas-dev
>> >
>> >
>
>


More information about the Pandas-dev mailing list