19 lines
5.6 KiB
HTML
19 lines
5.6 KiB
HTML
|
<p>Something that really annoys me about most repository hosts nowadays is that all of them are highly dependent on using pull-requests to contribute code, when originally all VCSs had (and still have) ways to contribute via patches (that and the `patch' command) which can be sent via e-mail. Now, I understand that having these changes more accessible to the public would be useful, and mailing lists aren't always best. However, why not simply use the same infrastructure of an issue tracker and apply it to uploading patch files? They would be organized just like pull-requests are, and would essentially be the same thing as a pull-request... except directly with a patch file instead of having to go through such a long process just to contribute to a repository.</p>
|
||
|
|
|
||
|
|
<p>So, why are patch files better than pull-requests? First of all, pull-requests are still useful if someone makes a real fork of a project (not what they're calling 'forks' nowadays which is someone making a copy just to modify something and then merge it back into upstream). However, if I am contributing to a project it is much easier and faster to make a patch file than to deal with web interfaces endlessly just to contribute two lines of code. When you make a patch file the process is as follows: clone the repository, make the change, create patch file, submit patch file. Easy, right? Now, let's look at this same process for pull-requests: 'fork' a repository, clone your 'fork', make changes, push changes to your 'fork', and finally create the damn pull request. Patch files have 4 steps, while pull-requests have 5. You may say "Well, but that's only one extra step, it's not that bad". Okay, but let's move forward.</p>
|
||
|
|
|
||
|
|
<p>Pull-requests almost always require you to work with web interfaces for a good part of it, and everything that uses web interfaces is slow as fuck compared to native desktop applications (like my VCS client which generates the patch file), especially if you are concerned about privacy and use TOR + blocked JS + a shit ton of privacy add-ons.</p>
|
||
|
|
|
||
|
|
<p>Also, pull-requests will <b>always</b> require you to create an account on said website, which is always a pain in the fucking ass (hence why Google and Facebook have been doing so well by allowing you to log in to other services using your Google/Facebook account... please never do this). Meanwhile, with patch files, even though one could hypothetically require you to create an account it is not strictly necessary. Patch files can be sent to mailing lists, e-mail addresses, or a web form can be created where one can simply upload a patch file no account (although perhaps asking for an e-mail for updates).</p>
|
||
|
|
|
||
|
|
<p>Patch files also help add to the decentralized nature of many VCSs, so one is not dependent on one particular platform (eg. GitHub, GitLab, NotABug, etc.). Instead, each person can host their own repositories where ever they fucking want to and contributors don't have to go through hell (ie. the web) and back just to contribute a couple lines to fix a minor bug.</p>
|
||
|
|
|
||
|
|
<p>This being said, I congratulate <a href="https://savannah.nongnu.org/" target="_blank" >GNU Savane</a> for not requiring fucking pull-requests like everyone fucking else (this is probably mostly because they also allow you to use a variety of other VCSs other than Git). Only issue I would have is that they require you to log in (and some other issues that they have in general, but that's besides the point). Based GNU wins the day!</p>
|
||
|
|
|
||
|
|
<p>Now, some of you may be saying "Well, we should use pull-requests because they're more user-friendly!". Fuck you. We're hackers, we should all be used to the command-line by now. That aside, why can't all these GUI clients work with patch files instead? Common GUI clients such as the GitHub client could easily be configured to create patch files and automatically upload them to GitHub (or where ever else). How difficult would it be to have a simple menu item that says "export patch"? So I don't see how 'user-friendliness' is an argument. Just because something in "in the web" doesn't make it user-friendly, and it doesn't make it more efficient either. What's more, sometimes the older tools are more useful than the new ones! Yet for some reason something being 'old' is somehow a reasonable excuse to dismiss it as an option.</p>
|
||
|
|
|
||
|
|
<p>The web is useful for some thing, namely broadcasting and making information public (information such as text, music, art, etc.). It's a great place for sharing. However, that doesn't make it a great work place. What is the web good for in terms of code? The web is a great place to post things like screenshots, samples, binaries, code samples, patch files, etc. But no one in their right mind should think that we should be editing code in our damn browsers. Pull-requests aren't for 'publishing' something, especially because they require you to 'fork' it. Therefore, it's not what we need in the web. Patch files are about publishing something, publishing changes in the code. What's the difference? The difference is that in the pull-request scenario one has the repository do the merging and has to 'fork' an entire fucking project while in the other a patch file is published to an issue tracker (you know, like in forum posts).</p>
|
||
|
|
|
||
|
|
<p>So please, stop promoting this cancerous disease known as "the pull-request". Patch files were perfectly fine. If you're going to write your own new repository hosting web framework or whatever, be sure to incorporate patch files. As I said before, pull-requests are good only if we're talking about <b>real forks</b>, not a 'fork' that someone made of a project to contribute 2 lines of code and then never touch it again.</p>
|
||
|
|
|