<p dir="ltr"><br>
On Oct 31, 2014 5:54 AM, "Daniele Nicolodi" <<a href="mailto:daniele@grinta.net">daniele@grinta.net</a>> wrote:<br>
><br>
> On 31/10/14 13:44, Stefan Behnel wrote:<br>
> > Daniele Nicolodi schrieb am 31.10.2014 um 13:07:<br>
> >> Thanks for applying the patch.<br>
> >> I see that you applied it manually and not through git am or similar,<br>
> >> otherwise my identity would have been recorded in the git metadata and<br>
> >> you would not have to add my name to the commit log.<br>
> ><br>
> > If I get a patch by email, I usually interpret it as: "here's a proposal,<br>
> > please apply or change as you like, I don't care about being named", unless<br>
> > stated otherwise.<br>
><br>
> As I tried to convey in my previous email, I don't care about being<br>
> credited, as long as the improvements makes into the project. The<br>
> question is rather: are patches by email ok for your workflow, or do you<br>
> prefer other means of sending contributions (pull requests or whatever)?<br>
><br>
> > Sorry for the misunderstanding.<br>
><br>
> There is no misunderstanding :)<br>
><br>
> >> I don't mind, but I'm wondering what is the best way to contribute<br>
> >> patches, to make your work easier. Should I go through a pull request on<br>
> >> github?<br>
> ><br>
> > If you want to appear in the history, then that's the way to go.<br>
><br>
> I don't care much about that, I just want to make your job easier.</p>
<p dir="ltr">Pull requests are best, but patches are just fine as well.</p>
<p dir="ltr">> >> I don't quite like this solution for trivial patches like that,<br>
> >> because it often ends up requiring a merge, and all the merge commits<br>
> >> make browsing the source code history harder.<br>
> ><br>
> > Merges are so common in DVCSs that most of the time I don't even notice<br>
> > them in the history. Except when someone else does the merge, as for pull<br>
> > requests. Then the distinction between committing and merging is actually<br>
> > relevant, as it shows which core developer takes responsibility for<br>
> > accepting a foreign change to the main repo.<br>
><br>
> If you apply a patch (in git patch format) from someone else, that<br>
> someone else ends up being the author, you are recorded as the committer<br>
> of the patch, so the information is there anyway.<br>
><br>
> But it is just personal preference. I prefer to avoid merges when the<br>
> repository history is linear, and I use rebase when my changes would<br>
> require a merge because of interleaved commits.<br>
><br>
> Cheers,<br>
> Daniele<br>
><br>
> _______________________________________________<br>
> cython-devel mailing list<br>
> <a href="mailto:cython-devel@python.org">cython-devel@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/cython-devel">https://mail.python.org/mailman/listinfo/cython-devel</a><br>
</p>