4 ms·

To be honest I never understood the value proposal of Github. Ok, you get git repository hosting, and list of projects, and that's pretty much about it, with th

To be honest I never understood the value proposal of Github. Ok, you get git repository hosting, and list of projects, and that's pretty much about it, with the ability to browse code online without cloning. Besides, that, I personally find most of the features useless. For example issue tracker is unusable, concept of forks is just a small convinience that doesn't add any real value. And about the most praised feature, like pull request, I find it just annoying and too much work. As a potential committer, it's much easier to me to clone the original repo and send a format-patch set then to bother creating my fork, cloning the fork, creating branch, pushing branch and writing an issue. As a maintainer, I also find it more convenient to just deal with format-patch set or an url to repo/branch than to deal with Github pull request system. And Linus tends to agree with me on this ;) That all being said, I still use Github for OS projects for visibility, I just don't accept pull requests, and Bitbucket for private projects because of unlimited free private repos. And I find them both useful, just not groundbraeking.

andybak 13y ago
First some context - I'm by no means a Git power-user. I learnt it under duress and would have much preferred Mercurial but at that point it was obvious which way the wind was blowing. Back in SVN days I also used to be quite fond of Google Code as it is was much cleaner and simpler than Github to my eyes (bearing in mind that a lot of Git terminology was unfamiliar to me back then). But once I learnt enough Git to get by, I started to love Github. My standard workflow when I need to use a 3rd party app for a project is: 1. Find the original repo on Github, 2. Browse the network to see if any of the forks are more actively maintained or have enough additions to be worth considering pulling from. 3. Fork the best fork to my own account. 4. Make the changes I need and issue pull requests if I think upstream would be interested. I've never learnt how to use patch sets. If someone sends me a pull request, it's 2 clicks to merge it. I'm sure patch sets aren't terribly hard but I can't see how they'd be easier than that.
- levosmetalo 13y ago
  > I've never learnt how to use patch sets. If someone sends me a pull request, it's 2 clicks to merge it. I'm sure patch sets aren't terribly hard but I can't see how they'd be easier than that. It's a few clicks if all you want is just to _blindly_ accept and merge it, without having it on your own computer before merging and being able to compile it, run a test suite, or perform some non trivial modifications to patch. For this purpose, to me is much easier to just apply the patch set in my local tree, or add a new remote and checkout branch then to deal with github pull request.
  - andybak 13y ago
    What is this 'compile' of which you speak? (and slightly more sadly) What is this 'test suite' of which you speak? :-(
dasil003 13y ago
Well git was invented for Linux kernel development, and Linus had his workflows dialed in years before GitHub was even founded (probably before Tom & Chris even started using Ruby). With his tree of lieutenants and long-standing email based workflow of course GitHub is going to be weaksauce for him. But as for you, I'm a bit confused as to what you really want. You say issues are unusable, which I can only assume is because they do not have the extensive feature set of proper bug tracking systems, but then you also say that pull requests are too much work. GitHub is clearly trying to do for programmers a bit of the 80/20 thing that Apple does for consumers, or what 37signals did for project management—give simplified tools and workflows that are easy to learn and use even if they aren't suitable for all use cases. If you're a long-term *nix hacker with a keyboard fetish then I can see how it might not seem that novel or useful, but for new developers coming up without the baggage, GitHub is bringing tremendous value, as demonstrated by the surging user uptake.

andybak 13y ago

First some context - I'm by no means a Git power-user. I learnt it under duress and would have much preferred Mercurial but at that point it was obvious which way the wind was blowing. Back in SVN days I also used to be quite fond of Google Code as it is was much cleaner and simpler than Github to my eyes (bearing in mind that a lot of Git terminology was unfamiliar to me back then). But once I learnt enough Git to get by, I started to love Github. My standard workflow when I need to use a 3rd party app for a project is: 1. Find the original repo on Github, 2. Browse the network to see if any of the forks are more actively maintained or have enough additions to be worth considering pulling from. 3. Fork the best fork to my own account. 4. Make the changes I need and issue pull requests if I think upstream would be interested. I've never learnt how to use patch sets. If someone sends me a pull request, it's 2 clicks to merge it. I'm sure patch sets aren't terribly hard but I can't see how they'd be easier than that.

levosmetalo 13y ago
> I've never learnt how to use patch sets. If someone sends me a pull request, it's 2 clicks to merge it. I'm sure patch sets aren't terribly hard but I can't see how they'd be easier than that. It's a few clicks if all you want is just to _blindly_ accept and merge it, without having it on your own computer before merging and being able to compile it, run a test suite, or perform some non trivial modifications to patch. For this purpose, to me is much easier to just apply the patch set in my local tree, or add a new remote and checkout branch then to deal with github pull request.
- andybak 13y ago
  What is this 'compile' of which you speak? (and slightly more sadly) What is this 'test suite' of which you speak? :-(

dasil003 13y ago

Well git was invented for Linux kernel development, and Linus had his workflows dialed in years before GitHub was even founded (probably before Tom & Chris even started using Ruby). With his tree of lieutenants and long-standing email based workflow of course GitHub is going to be weaksauce for him. But as for you, I'm a bit confused as to what you really want. You say issues are unusable, which I can only assume is because they do not have the extensive feature set of proper bug tracking systems, but then you also say that pull requests are too much work. GitHub is clearly trying to do for programmers a bit of the 80/20 thing that Apple does for consumers, or what 37signals did for project management—give simplified tools and workflows that are easy to learn and use even if they aren't suitable for all use cases. If you're a long-term *nix hacker with a keyboard fetish then I can see how it might not seem that novel or useful, but for new developers coming up without the baggage, GitHub is bringing tremendous value, as demonstrated by the surging user uptake.