GitHub “pull request” is proprietary, incompatible with Git ‘request-pull’ (was: debian github organization ?)
Russ Allbery <rra@debian.org> writes:
> Ben Finney <ben+debian@benfinney.id.au> writes:
> > Yet it is exactly those lock-in features that is the basis for
> > arguments to put special effort into the centralised single point of
> > failure.
>
> > For example, the centralised proprietary GitHub “pull request” is
> > presented as a reason to abandon a decentralised model:
>
> Uh, a pull request isn't something proprietary. It was part of the
> design of Git from the beginning and is based on the workflow of the
> Linux kernel.
The Git pull request (‘git-request-pull(1)’) is not proprietary. I
didn't claim that.
Indeed, Git's ‘request-pull’ works in a federated way, allowing peer
repositories on different hosting services to collaborate without
needing to establish an account on each other's services.
This is why the Linux repository, for example, deliberately opts to keep
using the standard, federated Git ‘request-pull’ feature
<URL:https://github.com/torvalds/linux/pull/17#issuecomment-5654674> and
not the GitHub “pull request” feature.
The GitHub pull request function is *not* compatible with Git's
‘request-pull’. It mangles them on the way in, and it doesn't produce
them going out.
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.
Git repositories outside GitHub cannot interact with the GitHub pull
request workflow using Git's own features.
(I've done some searching to try to disprove this with recent
information; if this has changed since 2010, I'd like to know
<URL:https://github.com/blog/712-pull-requests-2-0>.)
Emma Jane Hogbin Westby has a useful perspective on this too
<URL:http://developerworkflow.com/resources/evolution-social-coding.html>.
> Of course not. You don't have to use anything you don't want to use,
> and no one in this thread is advocating otherwise, at least that I've
> seen.
If a project uses GitHub pull requests for their workflow, they are
thereby prejudicing their workflow against repositories not hosted on
the proprietary GitHub service.
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.
That's not cool, no matter how nice the UI is for the proprietary
feature. That's damaging to a collaborative software community.
> All that I'd ask is that, if other people want to use GitHub, for you
> to not be an ass about it, the same way that we don't lecture people
> for using a proprietary editor to write free sofware.
Sure, so long as their decisions don't hamper anyone's ability to
collaborate with them.
If they use proprietary features of that tool which hampers
collaboration with others in the community, I hope you'll agree that's
something to object to.
> Sometimes I wonder if people think free software is so fragile that if
> anyone who works on it ever touches non-free software, everything we
> built will crumble. I think our community and ecosystem is a lot more
> robust than that.
Conversely, I wonder why people are so eager to cede the power of peer
collaboration by setting up single-vendor services as mediators of our
peer relationships. Surely we have seen that fail far too many times to
be led down that path yet again.
--
\ “[…] we don’t understand what we mean when we say that [God] is |
`\ ‘good’, ‘wise’, or ‘intelligent’.” —Karen Armstrong, _The Case |
_o__) For God_, 2009 |
Ben Finney
Reply to: