Re: GitHub “pull request” is useful and can be easily integrated'’
On 19 April 2015 at 21:00, Ben Finney <ben+debian@benfinney.id.au> wrote:
> Neil Williams <codehelp@debian.org> writes:
>
>> On Sat, 18 Apr 2015 17:55:17 +1000
>> Ben Finney <ben+debian@benfinney.id.au> wrote:
>>
>> > GitHub's pull request feature is proprietary to GitHub, it can only
>> > work between repositories hosted inside the GitHub silo, and any
>> > project using that feature is thereby locking its workflow to the
>> > single-vendor GitHub service.
>>
>> Not true. Simply and completely untrue.
>>
>> The pull request exists on github, fine.
>
> How can a collaborator Alice, with no GitHub account, get the pull
> request?
For the metadata:
- Via the web UI or HTTP API.
For the repository:
- via git over https://
[Unless the host organisation has paid for private repos of course...
but thats exactly the same as Debian security embargoed patches: a
collaborator cannot get those patches without an account.]
>> I can either choose to manually pick that out of the github interface
>
> I don't know what this means. How does that interact with the repository
> a collaborator Alice, with no GitHub account, is using with standard
> Git?
The person that create the PR did so by pushing a git branch to a git
repo. So the interaction is 'its a git remote'.
>> or I can choose to use my github account to merge that pull request
>> into a local branch.
>
> So this option supports my point that the GitHub pull request is siloed,
> and one must have an account with the single vendor in order to access
> it.
No it doesn't. The thing you didn't know what it meant, which I've
explained above, contradicts your assertion.
>> > Git repositories outside GitHub cannot interact with the GitHub pull
>> > request workflow using Git's own features.
>>
>> Untrue. I use github and git.linaro.org side by side and have applied
>> github pull requests as reviews on review.linaro.org
>
> How does a person Bob, using their GitHub repository, send a pull
> request to Carol using only their ‘review.linaro.org’ repository?
review.linaro.org is gerrit. So git push to the magic gerrit repo on
review.linaro.org the branch pulled down from github.
> Does Carol need a GitHub account and repository hosted at GitHub? If so,
> that's the point I'm making: GitHub's pull request can only be received
> and handled by another GitHub repository.
No. The metadata will remain where it was of course (on github) - its
not part of the git history. And this is exactly the same as for a
patch up in the Debian BTS.
>> > They have chosen (or have never been aware they made the choice) to
>> > make it much harder to interact with them using the existing,
>> > standard, federated Git ‘request-pull’ feature, instead opting to
>> > exclude anyone who doesn't want an account on a specific vendor's
>> > service.
>>
>> Sorry, that makes no sense. Working with github as a second remote is
>> trivial.
>
> How does a collaborator Alice, with no GitHub account, access Bob's
> repository on GitHub and use the standard ‘git-request-pull’ to make a
> pull request to Bob? How does this interact with the GitHub pull request
> feature?
I don't know of anyone using git-request-pull. I presume Linux uses
it, but does anyone else?
> How does Bob make a pull request to Alice, using GitHub's pull request
> feature, such that Alice can handle it using standard Git?
All PR's can be handled using standard git.
> Your descriptions so far seem to support the position that Git
> ‘request-pull’ is equal for all peers, is incompatible with a
> workflow based on GitHub pull requests, and that GitHub pull requests
> cannot be received and handled using standard Git commands.
git request-pull doesn't send anything to anybody: it is simply a
template email specifying where a repository is and what branch to
merge. Thats not a code review system, its *at most* the start of one.
Its also not a standard (unlike git-format-patch [1] which is - its
output is machine readable and intended to be consumed directly). Some
projects would accept git request-pull as a way of submitting a patch
- but only some [specifically those where code review is on a mailing
list && they aren't using http://jk.ozlabs.org/projects/patchwork/ or
similar - or they have one and only one committer and you're talking
directly to them every time].
git request-pull is thus inapplicable to many projects, since it won't
meet their needs. Similar GitHub PR's don't meet all projects needs,
so many projects don't use them.
> My point is to refute the notion that GitHub pull requests are open and
> equal for all peer repositories. Please show specifically where I'm
> wrong on that.
They are open - documented API, documented schema (we've had this
debate before!), except for private repositories, code stored in bog
standard git repos anyone can access.
So far, you haven't made your case at all AFAICT. Have you used
github? If not you should: the best position to critique a system from
is one of familiarity.
-Rob
1] https://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html
--
Robert Collins <rbtcollins@hp.com>
Distinguished Technologist
HP Converged Cloud
Reply to: