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