cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: making github a curl citizen, or curl a better githubber

From: Kamil Dudka <kdudka_at_redhat.com>
Date: Thu, 26 Feb 2015 10:36:22 +0100

On Wednesday 25 February 2015 23:37:16 Steve Holme wrote:
> On Wed, 25 Feb 2015, Daniel Stenberg wrote:
> > You all know how I (and some of you) have insisted that people should
> > not do pull request on github and instead post them here for review etc.
> >
> > I'm slowly beginning to realize that I'm fighting an uphill battle that I
> > will lose.
> I believe pull requests have their advantages and disadvantages:
>
> * I like them because you don't have to be subscribed to the mailing lists
> which a) some people may prefer and b) may result in more contributions.
> However, from a review (or even are we interested in the fix/feature)
> perspective the mailing lists offers a larger audience IMHO. For example PR
> 141 was created five days ago and only today did I see it and comment on it
> - even though I am subscribed (as I've not been performing any curl duties
> over the last week or so).
>
> * Users are able to view and comment on the changes without having to
> apply/review a patch file - an advantage (but off list and again to a
> limited audience)
>
> * It offers an easy way to merge the PR. However, I would prefer it if we
> don't merge them via Github as I don't believe this facility a) allow
> comments to be fixed up (to our standards), b) patches to be tweaked or
> minor coding style fixes to be made without additional commits and c) it
> also creates a mess in the log in graphical tools such as TortoiseGit - not
> too sure about in text based UIs (ie from the command line) rather than
> allowing the commit to be rebased and applied cleanly - in that respect I
> prefer to download the change as a patch, apply it to my repo, rebase and
> squash any fixes before pushing.

I fully agree on this. We should not fight against github pull requests
because they make it really easy to contribute. However, I would prefer
not to merge them into our git repo unless we have a strong reason to do
so (e.g. merging a separately evolved project into curl repository). If
we keep the history linear, it will make the repository more compact and
easier to work with.

Kamil

> * Unless I have missed something and go about it a long winded way, there
> doesn't seem to be an obvious way to download the change as a patch file -
> no "Download as patch" button. Instead I go to the URL and add ".patch" on
> the end. I then view the source of the page, save it and change the line
> endings before applying it to my local repo.
>
> Kind Regards
>
> Steve
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-02-26