Patches vs. 'git pull'
wknight8111 at gmail.com
Tue Nov 30 13:54:04 UTC 2010
Thanks for the insight Jim. Personally, I have found pull requests
much easier to deal with than patches. Of course, I've been doing so
many because of GCI that I've worked out something of a system for it.
Also, I've found myself getting a little bit frustrated by ordinary
patches. This might be because I'm not nearly familiar enough with the
git patch format or the relevant git commands. I suspect if I
practiced it more, I would be better and faster at it, but right now
it just doesn't work for me and I stick with the pull requests.
Of course, I think I still have a lot to learn about how to do pull
requests better and more efficiently, but that's another issue
Github does seem to provide a facility to download pull requests as
patches, so that seems like a nice medium. If you look in the
directions on the bottom of the pull request time you'll see there is
a command to use curl to download the complete text of the patch. I
suspect that could easily be done in a brower or through other means.
This seems like a nice medium while we are working out all the details
of our new process flow.
What I don't think I want to see is for us to be completely limited to
a single mechanism for accepting contributions. Clicking the big "Pull
Request" button is so easy for new contributors, while applying raw
patches seems to be much more familiar to some of our more experienced
Creating some kind of documentation for committers to talk about how
to accept contributions in various forms might be a very good task to
do soon. The more information we all have, the better off we will be
as a community.
On Tue, Nov 30, 2010 at 7:16 AM, James E Keenan <jkeen at verizon.net> wrote:
> In recent weeks, I've begun to receive many 'git pull' requests. Some of
> these relate to code which is now being developed outside the main Parrot
> repository (https://github.com/parrot/parrot). Example: We extracted PIRC
> from our main repository and placed it in its own.
> Others of these requests, however, pertain to code which could just as
> easily be submitted in the form of (a) attachments to post to this list, (b)
> attachments to Trac tickets, or (c) IRC pastes (via tools/dev/nopaste.pl).
> Speaking for myself, I find the mechanics of all of these easier to deal
> with than 'git pull' requests. Example: Last night I was asked to do a
> 'git pull' for a two-line patch. It was easier for me to simply re-type the
> code and commit it.
> Since (not for the first time) I am questioning the status of git as the
> Greatest Thing in the History of the Universe, I realize I run the risk of
> starting a flame war here. However, I seem to recall that pmichaud said
> that the Rakudo folks were perfectly happy to accept ordinary patches.
> So, again speaking for myself, I'm going to assign a higher priority to
> responding to patches submitted via (a), (b) or (c) above than to 'git pull'
> requests. In particular, if I'm interacting with people on #parrot, I can
> apply patches submitted via 'nopaste' much more quickly than 'git pull'
> Thank you very much.
More information about the parrot-dev