4 ms·

The real breakthrough wasn't github, but patch by Larry Wall, http://groups.google.com/group/mod.sources/browse_thread/thread/c5240ceb77b7f586/488b0929254d936a

by fhars 16y ago

The real breakthrough wasn't github, but patch by Larry Wall, http://groups.google.com/group/mod.sources/browse_thread/thread/c5240ceb77b7f586/488b0929254d936a http://groups.google.com/group/mod.sources/browse_thread/thr... together with UUCP. In the grand picture, github is just a nice frontend to patch that also replaces UUCP with something more modern.

jrockway 16y ago
I'm a hardcore UNIX fan that hates "social networking", but Github is really a major advancement over patch + email. Here are a few questions that might come up if you aren't using Github: "Is what I'm patching the canonical source?" "How do I set up my own VC for my patchset I'm maintaining?" "Am I sending my patch to the right person?" That adds up to mental friction that distracts from actually writing the patch. With Github, you click a button and get your own repository. You click another button to inform the author (and! other people with their own forks, if you want). The author accepts your patch and the revision history has your name attached to it. It makes it so easy that there is no excuse not to fix that tiny bug. Especially documentation bugs... you don't even need a git client to fix those!
- kamaal 16y ago
  The trouble isn't in installing git, or interacting through mailing lists. The trouble is in getting started. In order to contribute to something(fix a bug/develop something new) one has to understand what the expected behavior of the software is, how is it deviating from the current behavior. How and what can one do to correct it. This involves understanding of many things. Technology, the programming language and some CS areas. All of this most of the times a little out of reach of the ordinary day to day to programmer. The problem in simple words is 'The barrier to entry' to contributing most Perl/Python interpreter kind of projects is too high. You need to know a lot to do anything there. I think that prevents most people from contributing even if they want to contribute.
itsadok 15y ago
I'm not an expert in Unix history, but I think that long before "patch" the tool, the output of diff was a script that you could use as a patch by piping it into ed.

by fhars 16y ago

jrockway 16y ago

I'm a hardcore UNIX fan that hates "social networking", but Github is really a major advancement over patch + email. Here are a few questions that might come up if you aren't using Github: "Is what I'm patching the canonical source?" "How do I set up my own VC for my patchset I'm maintaining?" "Am I sending my patch to the right person?" That adds up to mental friction that distracts from actually writing the patch. With Github, you click a button and get your own repository. You click another button to inform the author (and! other people with their own forks, if you want). The author accepts your patch and the revision history has your name attached to it. It makes it so easy that there is no excuse not to fix that tiny bug. Especially documentation bugs... you don't even need a git client to fix those!

kamaal 16y ago
The trouble isn't in installing git, or interacting through mailing lists. The trouble is in getting started. In order to contribute to something(fix a bug/develop something new) one has to understand what the expected behavior of the software is, how is it deviating from the current behavior. How and what can one do to correct it. This involves understanding of many things. Technology, the programming language and some CS areas. All of this most of the times a little out of reach of the ordinary day to day to programmer. The problem in simple words is 'The barrier to entry' to contributing most Perl/Python interpreter kind of projects is too high. You need to know a lot to do anything there. I think that prevents most people from contributing even if they want to contribute.

itsadok 15y ago

I'm not an expert in Unix history, but I think that long before "patch" the tool, the output of diff was a script that you could use as a patch by piping it into ed.