Re: GitHub's ³pull request² is proprietary lock-in

Christian Gollwitzer auriocus at gmx.de
Sun Jan 3 03:33:36 EST 2016


Am 03.01.16 um 09:03 schrieb Ben Finney:
> Christian Gollwitzer <auriocus at gmx.de> writes:
>
>> Arguably, the most valuable outcome of the pull request in the end is
>> the patch, which is of course contained in the git repository.
>
> Arguably, the most valuable outcome of a database system is the query
> result, which is of course contained in the result set of tuples
> contained in the response data.
>
> Arguably, the most valuable outcome of a version control system is the
> source code tree, which is of course contained in a filesystem directory.
>
> Arguably, the most valuable outcome of a programming language is the
> programs we write with it, which is of course contained in the compiled
> binary.
>
> By your reasoning, that means we should not care about handing the
> control over our database system, our version control system, or our
> programming language to a vendor-locked, proprietary, gratuitously
> centralised technology.
>
> I hope the analogy makes it clear why that's not an argument I think
> anyone would accept as sound.

There are layers. Below your Python code there is CPython, below that 
the C compiler, the OS, and finally the hardware. If you are using an 
Intel CPU, you can't control the interpreter of the x86-64 machine 
opcodes. At some point, nobody cares. It's a question where to put the 
border. In former times, people sent emails with patches attached. 
Nobody complains that those emails are lost to the community. Then 
somebody invented VCS and all became better. Pull requests are nothing 
but elaborated emails.

>> I doubt that many people want to go back to see the arguments for a
>> certain merge
>
> I doubt many people want to go into the source code for my operating
> system and tell me exactly what it's doing, where my data is stored, how
> to get it from this operating system to a different one.
>
> My freedom to migrate from that system to a different one when I choose,
> is entirely dependent on *anyone* being able to do that, no matter how
> few people express an interest where you might see it.

You can still migrate, because git stays git.

	Christian





More information about the Python-list mailing list