Hacker News new | comments | ask | show | jobs | submit login
Leaving Github (bytbox.net)
229 points by srl on Aug 12, 2012 | hide | past | web | favorite | 142 comments



You can still get the full git diff out of a pull request by appending .diff to the pull request URL on github. Even better, you can get output similar to git send-email by appending .patch.

Likewise there's nothing stopping you applying an emailed patch in your local copy and then pushing to github.

This post seems to be making a mountain out of a molehill.


Actually, it's better to use '.patch' as we format that output specifically for 'am'. The '.diff' extension is for GNU patch or 'git apply'.

GitHub pull requests are made to be compatible with 'git am' on the command line and is documented in the GitHub "Using Pull Requests" help article under the heading "Patch and Apply":

https://help.github.com/articles/using-pull-requests/


Still fundamentally broken, in that it doesn't provide an option to receive these as email attachments.

http://www.wired.com/wiredenterprise/2012/05/torvalds_github...

> Torvalds says he brought up his problems with GitHub’s creators, but “they didn’t think they mattered.”

This is the crux of the problem. GitHub spends a great deal of resources working on a mac app and a windows app, which aren't interesting to people who do things the UNIX way at all. Meanwhile support for a good git workflow falls by the wayside.

It would be a substantial improvement if you could just remove the Pull Requests tab, along with the Issues tab.


> This is the crux of the problem. GitHub spends a great deal of resources working on a mac app and a windows app, which aren't interesting to people who do things the UNIX way at all.

I don't think you understand what github is and what their goals are at all. Besides that this is bad "zero sum game" thinking.

Hint: UNIX nerds that use mutt and are perfectly happy with the standard git command-line client and using send-email or am are already served. They don't need and clearly (proven by your comment) don't want github all. Yet people clearly love github and many use the mac and windows clients. Many non-programmers are even using github for things that aren't even (entirely) code projects.

If you don't want to use pull requests or issues, just state in your README under "how to get your changes merged" and "where to log issues" what people should be doing if they want to collaborate on your project.


Interested by non-code projects. Got some examples? Right now I can only think of the German law and that Wired article about Github.



You couldn't just remove the Pull Requests and Issues tab. You'd need to replace it with something detail the alternate contribution workflow.

Also quick ignorant question: Does the diff patch approach eliminate the need to fork a project to contribute to it? I like the idea of forking for a project I plan on contributing a bunch to, but when I just want to contribute a bug fix or some tests, I find having to fork to be completely unnecessary.


> You'd need to replace it with something detail the alternate contribution workflow.

Yes, it would be closer to an equivalent workflow if the the project owner would mention it in a README. But savvy users could send a nice patch email using only instructions in the git man pages (man git has a list of commands).

> Also quick ignorant question: Does the diff patch approach eliminate the need to fork a project to contribute to it? I like the idea of forking for a project I plan on contributing a bunch to, but when I just want to contribute a bug fix or some tests, I find having to fork to be completely unnecessary.

It does. It's quite excellent being able to do a one-off patch.


> It does. It's quite excellent being able to do a one-off patch.

That alone I think is an excellent reason to support this feature and a much stronger argument than "Pull requests aren't native to git". I really wish submitting one off patches didn't require forking.


> Likewise there's nothing stopping you applying an emailed patch in your local copy and then pushing to github.

Right. Now let's say you are the one not using github (you use raw git), and you want to send a patch to somebody using github ("not git"). As TFA notes, either nothing gets done (you send-email and the other guy just doesn't see/want it) or something has to give, you have to create a github repository with the result of your patch or the other guy has to learn git-am.

That could be fixed if github had better mail integration (and more generally more hooks for standard git behaviors) and you could essentially create a pull request by git-send-mail-ing some sort of special address @github. And the pull request got its own mail thread (so the initial sender got replies & al without needing to go on github).

As far as I know, that's not the case.


That's something that github could easily add, given their current level of resources. The million dollar question is "why haven't they added it?" There are at least two possible answers: not many people have asked for it, or to increase lock-in.

It's a feature that github SHOULD add. There are some people who want it, and these people are the type of people that can become quite vocal proponents or detractors.

More importantly it signals quite strongly that github intends to become a good citizen in the nation of git rather than trying to appropriate it.


> There are at least two possible answers: not many people have asked for it, or to increase lock-in.

Watching Zach Holman's various presentations on Github and how they work interally provides a third one: since Github uses pull requests internally (and new githubbers are probably github users in the first place) nobody has any issue with not supporting `am` and `send-mail` there, so nobody went and built support for that.


As TFA notes, either nothing gets done (you send-email and the other guy just doesn't see/want it) or something has to give, you have to create a github repository with the result of your patch or the other guy has to learn git-am.

Or you know he checks his email and takes the patch. When you use github you are using git. There is no way to commit from the github website, so if they have code on github then they must have interacted with git. Now that we have established they interact with git then they have the capability to interact with the patch feature if they so desire.


Actually, you can commit from github. Go to any file and hit Edit at the top right. It's a single file editor, so don't expect much out of it, but it is conceivable for someone to contribute without using git.

And to your point, you cannot add files via github.


Yea. At the end of the day, it's still a git repo that you're dealing with. This post is a lot of hot air.


That's exactly what I thought. Whats all that talk about it not being compatible with git and a separate protocol? It's just plain git, you could still apply a patch received my email locally and upload it. It seems to be a lot of whine and very little suggestions. I remember seeing Linus Torvalds writing that it is one of the best options for hosting git, even though he was not a huge fan of pull requests either.


Yes, but he's kind of right - they could do better.


I wholeheartedly disagree. This is like complaining about the mars mission saying that their pictures are not HD enough and they could do better. No they couldn't and they would if they could.

Well since I'm already downvoted I'll just finish this rant. Comments like this frustrate me, why would you just assume something could be done better just because it is easy to do? Everyone read how Github works, it's a collective of programmers that assign themselves tasks, anyone at github could for themselves decide to implement this feature. No one did, obviously they've got something better to do! Don't tell me every employee at github is an evil corporate overlord that wants to vendor lock the world into github.

They make the best source control repository in the world, and you should unequivocally laud them for that.

Frankly if you don't, I think you're a bit of a retard, so that brings me to the linked article. It makes no sense at all. Github does nothing fundamentally wrong, and it is not incompatible with how he or anyone else uses software.

If a project requires you to submit a pull request via github, how is that different from a project requiring you to submit a bug through mozilla? It's just not. If you think you and your patch are so important you shouldn't be bothered with pull requests, why don't you just fork and put it on a repository somewhere else?

As if e-mailing patches to people is somehow more effective at getting them to merge code. As if git am is somehow a fundamental property of git, instead of just some feature Torvalds hacked onto it.

I would like to rant about more invalid points he makes about github being a 'reimplementation' of git, but he doesn't make any other points.


By that measure, as long as a company stays busy on their product, they've built the best product they could.

That sounds like hippy hand-wavy BS to me.

As a software engineer who works at a Bay Area startup with a pick-your-own-tasks model, we still (like GitHub) have product managers who give input and direction into features and product design. Just saying that the decisions they've made about how to allocate resources are the best possible decisions they could have made is just giving them (or anybody else) too much credit.


I see your point, I'm not saying that GitHub isn't awesome. I love it and I am really convinced that it has revolutionized the way collaborative projects work. That doesn't mean it can't be better.

Being a distributed version control system, Git supports different workflows. Pull on demand is one of them, but mailing patches is an equally valid option. Git was initially conceived with the kernel's particular workflow in mind, and `git am` is fundamental in that process. Do I find it as easy to use as what GitHub offers? No, but supporting it wouldn't hurt and it would bring some old-school developers to GitHub's side.


They could start by treating users like they own their projects. There is no way to remove the Pull Requests tab. This is, or at least would have been, trivial to implement. It stems out of the idea that users can't make decisions for themselves. You can listen to 5by5 podcasts 10 hours a week to convince yourself that this is the right way, but from a user empowerment perspective, it isn't.


He may be exaggerating, but what he is trying to say is that he rather not invest in a tool/platform whose product development is out of his control and may be on a path contrary to what he wants out of said tool.


Actually, he says more than that. He calls GitHub a fad, not likely to last. Which is fine, but his argument is predicated on more than just what you state.


This post is so neckbeardy I feel itchy all over.

GitHub provides a lot more than the open source tools. Primarily it provides community. Most people would rather not have patches received by email. They would prefer a web-based interface where you can comment, adjust, and accept.

This is a classic case of not getting it.

You can manage your repo independently and push to GitHub when required. It's not even hard. If, as an open-source developer, you want me to log into your own personal bug-tracking system, your own personal source-control system, you've lost me as a contributor.


GitHub is closed source, but has open APIs to interact with every aspect of the system. It would be completely possible to create an email dropbox for git send-email that would create pull requests from an email. The reason that such a thing doesn't exist is that nearly everyone loves the crap out of GH pull requests.

If you don't like pull requests, you can use GitHub as nothing but a git remote. If you use https://github.com/defunkt/hub, you don't even ever have to visit the GitHub website once you've signed up.

GitHub does enhance and doesn't replace git. You're proclaiming an "embrace, extend, extinguish" when the fact is that nothing on GitHub is incompatible in any way with git off of GitHub. If one day GitHub were to torch their servers and disappear, all I'd have to do is git push to another remote and we're back in business. I'd lose my issues, but git doesn't exactly ship with an issue tracker.


"services like github and sourceforge are just fads, with very little (I think no) added value."

I can't tell if the author is being hyperbolic or is just out of touch with reality.

"A couple nights ago, I needed to set up gitweb (a story for another post), and learned that no, nginx did not support CGI, and fcgiwrap was a little annoying to get working on OpenBSD. I whipped up a quick 80-liner in go to serve a single CGI script, and then told nginx to reverse proxy." (from previous blog entry)

oh.


He's out of touch with reality.

Xanga, MySpace, Digg… the lists extends to infinity, and only fools could think that Twitter and Facebook, giants now, won’t be added to that list within the next five years.

I wonder if his tune will change in 5 years when Twitter and Facebook are still giants?

I'm not sure how much I'd be willing to bet that they'll still be "top dogs" in 10 years...

But asserting that "only fools could think they'll survive 5 more years" is crazy.


I agree with you about the 5/10 year deal, but I think it needs to be said why Facebook will survive, and why Xanga, MySpace and Digg did not.

All of the latter three sites did multiple things wrong:

1. Fail to compete with competitors 3. Fail to build a community

Issue 1 manifested itself differently for each site. Xanga couldn't keep up with LiveJournal, which not only arrived on the scene after Xanga but out-innovated them as well. MySpace was a clusterfuck of design and functionality that got stale while Facebook was improving constantly. Digg ignored the hell out of its users and simply had nothing compelling vs Reddit.

Also, none of the sites pulled in people and kept them. The narrative for MySpace users was that people were becoming "friends" with hundreds of people who they did not know. It doesn't take a genius to realize that this essentially invalidates the whole point of a social network. Xanga never got a large audience and also suffered from the same problem of anonymous users. Digg? Digg never even really tried. Shouts were pathetic.

Facebook solved these problems. While MySpace appeared to do nothing after News Corp acquired them, Facebok kept changing the site in a very public way--and even when they got negative publicity (e.g. privacy settings), they made sure that people knew they were actively developing the site. Additionally, users on Facebook know the people in their network, and users are constantly given a reason to come back (communicate with your friends! apps! interact with companies!). Faceboook survived because they made it clear that they are the best game in town.


Two things,

By his "standard" Gmail is just a fad... a 10 year fad.

And also, him using his own git server is fine and well until his server gets hacked.


gitweb can use fastcgi out of the box (first Google result: http://sixohthree.com/1402/running-gitweb-in-fastcgi-mode).

Although I may agree with your comment, it sounds a little bit like an ad hominem argument. He may be wrong in other posts but can be completely right in the post we're discussing here.


It is not ad-hominem, he is using proof from a different source than the original article to show that the author is just flat wrong about services like Github providing no value. In this case, the minimum amount of value Github was adding was the cost of however much time it took the article to mess around with Nginx and then write his Go script. Multiplied across the entire population of people using Git (keeping in mind that many of them probably aren't capable of solving the gitweb problem), that is already a sizable value-add.


Apparently you and I have very different definitions of "out of the box". The link you give explicitly requires installing and configuring a fastcgi wrapper script distinct from gitweb.


FastCGI is supported by gitweb, you need to install the dependencies and use a command line flag + env variable (that I think it's required by the module that implements the FastCGI bits). That's not a wrapper.

Read the INSTALL file: http://repo.or.cz/w/alt-git.git?a=blob_plain;f=gitweb/INSTAL... (Requirements, "optional Perl modules")

EDIT: ate a word.


Github is not like that. The github engineers quite clearly see github as a product built on git (the technology) rather than a product operating within git (the protocol). They do not improve or contribute to git itself

GitHub has a number of employees that contribute to libgit2 (https://github.com/libgit2/libgit2), and the language bindings for a number of languages. I think that is a serious contribution to the Git ecosystem.

full disclosure: I replaced GitSharp with LibGit2Sharp (the C# bindings to libgit2) in Git-Tfs


This is quite an audacious article, considering that the author's web-interface to his destination git repo is not set up properly:

http://git.bytbox.net/

  <base href="http://localhost:8081:8081" />
  <link rel="stylesheet" type="text/css" href="static/gitweb.css"/>
  <link rel="alternate" title="bytbox.net Git projects list" href="?a=project_index" type="text/plain; charset=utf-8" />
  <link rel="alternate" title="bytbox.net Git projects feeds" href="?a=opml" type="text/x-opml" />
  <link rel="shortcut icon" href="static/git-favicon.png" type="image/png" />


Yep, it's still broken.

<base href="http://git.bytbox.net/ /> fixes that page, but pages reached from there are still suffering the some bad base href.


I also get that "silo" feeling from git's pull requests, but for a different reason. That great big "merge & close request" button seems nice and handy, but if you press it, you're doing it wrong. You should probably be merging it locally, running your automated tests and some manual sanity checks, and then pushing it to github. What github should do is have a button that pops up a dialog containing some commands you can cut and paste to the command line to do just that. My flow looks something like this:

- click around to find the author's repository URL

- git remote add it

- git fetch that remote

- copy the author's issue branch name from the pull request page

- git merge that

- run the automated tests, and check functionality

- then either git push or delete my own master branch and then check it out as a tracking branch from origin/master

That last step is probably suboptimal, but it doesn't happen often and I know how to do it that way. It illustrates my point, though: why doesn't github tell me how to do it?


I've complained about this before too, but if you click the "i" with a circle around it in the bar that says "this pull request can be automatically merged" you get a nice box with all the git commands to do a local fetch and merge. I think this functionality should be less hidden away but it is there and quite useful.


You should check out Travis-CI. If setup, it will comment with the test results on your pull requests, e.g.: https://github.com/KristianOellegaard/django-hvad/pull/69#is...


For IPython, we now merge most pull requests by clicking the green button. It's convenient, and it automatically links the merge to the PR, so you can find the discussion associated with the changes. For testing, we have a script (test_pr.py) that merges and tests the changes, posting the result to a comment on the PR.


I recently had a PR I needed to take and improve. Getting the repo URL to pull it was surprisingly difficult.


I see this guy's point, and I understand it's not unique (we've seen Linus' thoughts on Github's Pull Requests), but personally I don't see it as a big deal. Pull Requests are very simple to use and in my experience, do what they are meant to very well.

I recently made my first contribution to an existing open source project, and it was an interesting experience. One of the things I always wondered was, how do I go from "Ok, I have a bug fix / new feature" to "Great, it's part of the software now!". For this particular project it was as simple as forking the Github repository, making my changes, and sending a pull request- done. I could leave that Github repo on my account to easily show off my contribution to friends or potential employers, or delete it if I felt it was clutter. I didn't have to learn how `git am` or `git send-email` work or making a patch and sending it to a development list or anything like that.

And if someone wants to contribute to a project of mine on Github, but they don't want to use Github's system, that's cool too. If you're willing to help me out, I'll gladly learn how to take your contribution and get it into my project.


Same with me. I recently made my first contribution to an open source project using Github. There is no way I would have done the same if I had to deal with patches, emails, arguing with other developers or some other process that wasn't as simple as a few clicks.

I honestly believe Github is the best thing to happen to OSS in a long time.


I was under the impression that GitHub stuff is orthogonal to git. In other words, GitHub pull requests don't make the existing git functionality go away and there's nothing stopping anybody from using whichever one they want. If you don't like GitHub pull requests just don't use them. Am I mistaken?


>Am I mistaken?

no. as others have pointed out in the last few minutes, GH is perfectly capable of being a standard git remote.

I've only found two limitations to hosting on GitHub:

* Can't use real git hooks. understandable in the shared environment, but an annoyance and it's worth mentioning.

* Can't prevent force pushes; no fine-grain permissions- grant read or read-write to a repo.

The permission gripe has a solution in GitHub Enterprise, but I don't use it and can't speak to its usability.


> Can't use real git hooks. understandable in the shared environment, but an annoyance and it's worth mentioning.

It's also worth mentioning that the selection of hooks available pretty much trumps any standard git hooks that I've ever dealt with. And if you really need some custom functionality to fire, you can set up a custom webhook URL that points to your own server somewhere.


This then requires exposing a crucial part of your development workflow at a public URL (even if the resource is authenticated). For various reasons, this is quite simply a non-starter for many shops who might otherwise be prepared to bite the bullet and put their source code on Github's servers.


> this is quite simply a non-starter for many shops

And, for those people, github offers an appliance that sits on your network.


Which is about 10x more expensive than hosted GitHub. No joke.


I didn't know github offered an appliance, that sounds like a good fit for those folks as long as it's priced reasonably.


It's actually absurdly expensive :(

It's a very cool app (Github, only on your own server, basically), but it's priced out of the range of anybody but large enterprises.


You're forgetting that there are other types of hooks besides post-receive.

"The first script to run when handling a push from a client is pre-receive. It takes a list of references that are being pushed from stdin; if it exits non-zero, none of them are accepted. You can use this hook to do things like make sure none of the updated references are non-fast-forwards; or to check that the user doing the pushing has create, delete, or push access or access to push updates to all the files they’re modifying with the push."

http://git-scm.com/book/en/Customizing-Git-Git-Hooks


I don't totally agree with the OP's rant, but I wanted to channel him here anyway:

But then you've got the issue that anybody interacting with your project on GitHub (eg sending GH pull requests) will see them go unanswered and lose interest in contributing to your project. This is pretty much the exact rant Linus Torvolds had a few months ago.

Yes you can put "I DON'T DO PULL REQUESTS, SEND ME AN AM" in your readme but anybody can agree that that's seriously deficient compared to a GH Pull Request feature that's compatible with AM. (Not that I think GH are evil for not implementing that, just that yes, it would certainly be better if it was implemented).


So basically:

"Don't implement pull requests because it is much nicer than Linus' solution, so if you implement it then everyone's going to want to use it and then when you insist on not using it no one will want to play with you. :("

Seems a bit like a flawed argument to me.


??

Or how about:

Progressively enhance the AM protocol so you can receive both basic AM requests from non-GitHub users OR produce a great UX (as it currently is) if both users are on GH.


> The permission gripe has a solution in GitHub Enterprise, but I don't use it and can't speak to its usability.

Surprisingly, there isn't any fine grained permission management in their Enterprise product. Their old FI product used to support hooks, but they've removed those features in Enterprise.

It wasn't that long ago a jr developer discovered the '+' flag to non-ff push and broke the hell out of one of our larger repos.

Good Times.


You could easily use a send-email/am workflow with a github repo. It'd be identical to using your own git remote.

It would also be possible for github to add a yourproject@github.com that accepts a send-email formatted patch mail and creates pull-requests.

The only reason these don't happen is because nobody really wants that. The first one is immediately and completely possible, but you'd get harrassed by all the people that want the pull request UX. The second would require effort on the part of github in order to please an audience of nearly zero.

Edit: Honestly I think you'd get just as much grief from the people who want pull requests when using a private repo ("Why not just use Github"), except maybe that they don't know your project exists. It's up to you if you want to care, regardless of where your remote is.


I'm sure I'll get downvoted for this, but the fact that github makes it so that I largely don't have to use git is why I use it.

Despite my best efforts, every time I try to use git I run away screaming in terror.

I've used sccs, cvs, svn, mercurial, and a few other version control systems over my development lifetime and I can just never wrap my head around git.

That may be because I spent so many years using Mercurial before git, but I just can't seem to bring myself to enjoy using it.

git makes things far more difficult than mercurial (in my opinion) and has encoded it's creators process and workflow into the tool.

Tools like github for mac (or the arguably superior tool, SourceTree) make git bearable for me.


This is, I think, a legitimate reason to use github (although I personally think you'd be much better off really forcing yourself to use and grok git).

But it would be better for the rest of us if, despite not using git, github made it look exactly like you were using git. But that's not quite the case - quite a bit of git's functionality is missing (cherry-pick), and other bits are replaced with non-compatible pieces (PRs vs am+send-mail, which provide the exact same functionality, but can't talk to each other). As things are, collaborating with you on a project would require me to use github's interface.

Or in reverse, if you wanted to collaborate with me on a project, you'd have to use raw git. If github supported foreign clones and PRs (via send-email and friends), it would seem much less "trapping".


Maybe http://hg-git.github.com/ is of interest for you then?


I thought this was about an employee leaving GitHub and thought "oh shit, there goes their winning streak"!

On the actual post: what prevents one from using `git am` locally and then pushing the changes to GitHub?


> On the actual post: what prevents one from using `git am` locally and then pushing the changes to GitHub?

Absolutely nothing. His entire 'Github vs Git' thesis is a false dichotomy.


In theory, nothing. In practice, most github users don't know how to use `git am`, and won't accept contributions but through github pull requests (or at least will get very annoyed).

In general, open-source projects place the onus on the contributor to make sure the contribution is packaged appropriately, for better or worse. Emailing patches around works very well, and modern VCSes have splendid support for it. If you want to contribute to a project on github, you need to abandon that.


> In general, open-source projects place the onus on the contributor to make sure the contribution is packaged appropriately, for better or worse. Emailing patches around works very well, and modern VCSes have splendid support for it. If you want to contribute to a project on github, you need to abandon that.

Rather: if you want to contribute to a project on github, and that project does not accept emailed patches for contributions, you need to abandon that. If the project didn't accept pull requests, you'd need to abandon pull requests.

This has absolutely nothing to do with Github, and everything to do with the preferences of the project maintainers and the reality that if you want to contribute to something, it's up to you to conform to its standards, not it to conform to your preferences.

Pull requests are popular with project maintainers simply because they're a very low-friction way to accept contributions.


Also, if you email the maintainers a patch and an explanation about why you don't use Github and humbly ask them if they'd accept the patch, I think there's a good likelihood they will if the patch is good.


>place the onus on the contributor to make sure the contribution is packaged appropriately

appropriately according to the standards of that project.

if using GH pull requests was such a barrier to entry, contributors wouldn't and you'd see an exodus from using them.

I haven't seen this.


"false dichotomy"

How can you commit to the linux kernel using github's interface? I have not seen a button for `git send-email`.


Apparently this isn't obvious, but when you push your repo to Github, you aren't actually handing complete control of it over to them. You can still `git send-email` from your CLI.


Perhaps the github people decided -- since in order to have a `git send-email` button you must first have actually committed a repo from your own machine, and that your CLI/local client has the facililty already -- that the feature being moaned about here was... what's the word?... optional.


Forgive me, I'm not nearly as familiar with the system as others, but couldn't you just clone the repo on your own system, then send that command from your own bash? It isn't using Github, yes, but then again that system setup doesn't seem like it's using Github either.


I think the point of the linked story is that you can use github seamlessly to collaborate with other GH projects but you have to use your local git installation for interacting with non-gh projects.


You have to use your own local git for doing anything non-trivial.

Github does not intend to replace your CLI, it intends to augment it. Reimplementing send-email/am would be a waste of their effort toward their true goal.


I'm not sure I understand the basis for your conclusion..

There's a lot of git operations you can't do with the Github web interface.

How do you do a non-ff merge? A rebase?

You use the git cli.


I think that is the thesis of the linked story. I did not write the linked story nor am I in complete agreement with the author. But I think that the thesis is that there is the github way and then there is the git cli way. To use the author's analogy to gmail, what actions do you drop to the shell to complete instead of using gmail's interface.


> But I think the thesis is there is the github way and then there is the goit cli way.

Which is, again, a false dichotomy. Github is a remote repo. In git you always also have your own local repo, and things like 'git am' and 'git send-email' (and 'git rebase --interactive', and 'git bisect', and any other non-trivial use of git) are operations that you would always want to be performing locally before pushing it out to a remote repository.

That there's no interface to perform these things on Github doesn't mean that Github is trying to engage in vendor lock-in, it's just a reflection of the reality of the fact that you should be doing that stuff to your local private repo, with your local client.


If that is the thesis, then his example of gmail is strange. After all, he uses fetchmail, alpine, mutt and Thunderbird to use the service. I strongly doubt that gmail has every single feature of mutt in their web UI!


It is also strange since gmails IMAP implementation is so horrible due to the way they changed how email works (labels, archive, etc).


I think the difference is that gmail wasn't the first simplification (web-based or otherwise) of email.

Remember when people used to sign (and/or encrypt) their emails with PGP/GPG? I'm not aware of a way to do that in gmail in any realistic sense.

I do remember, however, many early webmail clients barely supporting even small attachments. Some didn't support multipart.

Eventually, as webmail providers improved, the userbase decided the trade-off of losing the low-level access for the usability advances was worthwhile. I think email is an apt analogy.

GitHub is the first highly-successful incarnation of its kind. There are already credible competitors (albeit with much smaller user counts), and there will be more. GH has made a business decision on what features they spend time on. Other competitors will arrive at different decisions.

Developers, along with popular open source projects, will go to the providers that support their needs.


"Remember when people..." I have not forgotten, I still do.


Likewise and I thought from the first line ("I’ve done it, I’ve ditched github") it was going to be a scathing tear down of how their flexible management is going to be the death of the company. What a let down!


Yeah, that sucks I was really hoping to read an ex-githubber airing their dirty laundry complete with ad hominems and vitriolic gossip.

wtf?


Github is not loyal to the Git way of life. They reinvent or add sugar to parts of Git that do not appeal to amateur developers.

For example, Github for Mac hides the Git workflow with semantics that are similar to Dropbox and SVN. They have also switched the default authentication from SSH-based to username and password based.

This is very intelligent on their part. Less scary = more developers = solidified Github as THE code repo of the Internet.


Increasing the accessibility of Git isn't treason. Quite the opposite: Git is now used by far more developers. That's a win for the "Git way of life."

And the original, "expert" workflow is still available for those who want it.


> That's a win for the "Git way of life."

No it isn't. That's a win for the GitHub workflow. People learn how to use git locally, if they aren't using the mac or windows client. They don't learn how to collaborate the standard way, though.


Never said otherwise. As I said, Github is very intelligent to lower the barrier to entry.


I HATE the auth switch. Entering username and password is very irritating.


For people that have never setup SSH, HTTPS auth is very simple. The latest Git supports credential cachers so you don't have to type the password in each time. I also personally love that the same GitHub URL works in the browser and through the Git CLI.

If you click the "SSH" button on GitHub repositories, it'll remember your preference.


It never remembers, for me.

And thanks, now I know why only some repos ask for username/password.


It remembers for me, but their pull request emails always send the https link, which is annoying as shit. I emailed them about it, and their response was that they are trying to get everyone to use https, so no, they won't switch it or make it smarter.


Argh. I like my SSH credentials, my GitHub password is not quite so secure.


I complained about this too, but for their new repo screen.


It's a fairly recent addition to git (January 2012). You need at least version 1.7.9 to use credential caching. [1]

[1]: http://git-blame.blogspot.com/2012/01/git-179.html


I agree wholeheartedly with disliking their pull-request interface (the encouragement to use a non-mailed-patch workflow plus the fact that push notifications don't include diffs means that diffs never land in my inbox, which is unfortunate), and disliking the popular equivalence of Github with git.

That said, "They do not improve or contribute to git itself" is simply untrue. Many of the most active git contributors are Github employees. The git website itself was designed by Github people and is hosted by Github; the Pro Git book is written by an employee.


I see where the author is coming from with his arguments, but I'll bet 10 bucks his project won't be seeing any pull requests moving forward. Github did not supplant git, it created the market for git. If it weren't for github, we'd all still be using SVN (yes yes and mercurial and blah blah other minor league players).


I have little doubt that a great many of the programmers here adopted DVCS long before commercial web frontends became popular. You have it backwards: Github has git to thank, and not the other way around.


Er, both are true.

Github is fundamentally a "value added" on top of git. It obviously owes a huge amount to git's fundamentally good design, and especially in the beginning, to a pre-existing git community (which jumped at a somewhat slicker way to set up git repos and interact with other git users).

But OTOH, github's slick layer on top of git really helped push git into areas that might have been a harder sell otherwise. [and that's what's amazing about git these days: not that it's popular amongst hackers (duh!) but that it has become popular amongst more conservative corporations and less technically inclined users.]

They help each other. Win-win.


Let me spell it out for you: git would exist if not for github. The inverse is not true.


I doubt git would be nearly as popular without a really polished hosting site, though. Github is git's killer feature.

And there are other DVCSs. As it is, the main hosts for bzr and hg are clearly less slick and less popular than Github. But had Git not been there, it's quite plausible that someone would have built an equivalent site around another technology.


> I doubt git would be nearly as popular without a really polished hosting site, though. Github is git's killer feature.

GitHub isn't polished. It just has engagement mechanisms like twitter does, that keep people coming back. When people say how much they like GitHub they're usually talking about the community or git, both of which GitHub takes way too much credit for.

> And there are other DVCSs. As it is, the main hosts for bzr and hg are clearly less slick and less popular than Github. But had Git not been there, it's quite plausible that someone would have built an equivalent site around another technology.

There were a lot of people moving to git from hg when GitHub came out. I think it was clear there was demand, and if not for GitHub other services would have sprung up to fill in the gap.


Existence is hardly an impressive accomplishment.


I won't speculate on HN's userbase, but that I'm confident GitHub is responsible for a much of git's gains both in the wider open-source community and within startups.


This doesn't make sense. You can use Github purely as a git remote, and nothing else--just as you can use Gmail as an IMAP host, and nothing else.


> You can use Github purely as a git remote, and nothing else

And then you start receiving pull requests.

Github, purely as a git remote, adds no value over self-hosting, and is significantly slower. (Seriously - try self-hosting and notice how different 'git push' feels. It surprised the hell out of me.)


You don't receive pull requests if your repo is private.

So where is the value you are asking? Well for one, we don't worry about the server git is on going down. But more importantly, we are exposed to a lot of tools usable via the site that are hard to replicate on the command line. For instance, they have a great "view changes" feature for comparison between repos, this help sort out why master was ahead of development by some commits the other day. I could go on (stats, ease of sending links to diff to non-technical people that just want to see a text change was made, etc.) but go take a look yourself. That's not to say that git is for you, but your premise that github offers no value as a git remote is false.


  Well for one, we don't worry about the server git is on
  going down
github has been down for far longer in the past four years than the server where I keep my repositories, which has only been offline for maintenance reboot. This is my main reason actually for not wanting to put anything commercial on github; the performance benefits are just gravy on top of that.

  they have a great "view changes" feature for comparison
  between repos, this help sort out why master was ahead of
  development by some commits the other day
It sounds like you're referring to branches, not repositories. `git diff` handles this very well for me and is far more flexible. Even on an open source project I host on github, I'm going to use `git diff` to perform this operation.

  ease of sending links to diff to non-technical people
  that just want to see a text change was made, etc.
gitweb handles this fine if I need it to, though.


Yeah. And I could easily set up a box with postfix, an IMAP daemon a webmail and a spam filter.

But in my personal case it's a waste of my time compared to just using GMail. Obviously that's not true for everyone and I'm not trying to say it is. Nor do I thing the pro-Github folks in this thread are trying to say github is always the answer.


It is simpler and easier to set up a new git repository on a webserver than it is to do the same on github. It is also simpler to set up post-receive hooks and the like when you want them to do sophisticated things. The ramp-up to get git working on a webserver is this: Do you have SSH connection? Are your contributors' umask okay? To compare this to the complexities of configuring good SMTP/IMAP/POP with SSL shows that you don't know very much about any of these matters, or that you are not thinking seriously about them.

P.S. I find great benefits of hosting my own email, chiefly, once again, that I can guarantee that my mail service is working, and that I get my mail very quickly. gmail has been offline more in the past four years than my mail server. I also don't have to worry about password resets, a webmail UI constantly in flux, or Gmail constantly hitting me up for my mobile phone number.


I see your point, but for many people they don't want to setup their own webserver. Not everyone has the same skillsets - and often they don't want the hassle of troubleshooting their server when it does go down.

Horses for courses really :-)


>It is simpler and easier to set up a new git repository on a webserver than it is to do the same on github.

Is this a joke ?


If you already have a webserver, even just a ~/public_html folder (something very common for people at universities, for example, to have), anywhere on the Internet that you have SSH access to push content to (and honestly: I would find it highly unlikely that your average developer does not have at least one), you can push a local repository to it with a single shell command: you just push to a folder on the server as if it exists, it will be created, and the folder can then be used via the web server for anonymous git clones and pulls. As in: if GitHub requires even a single additional step of "type in the name of a repository into a website" it has already far lost; so no: it doesn't seem even remotely reasonable to insinuate that oinksoft's comment is "a joke". If you don't already have a working web server (again: seriously?) then setting up an account that has one in this day and age is really not going to be much harder than getting an account at github, and once you have one it will again be simpler per repository to push.


I'd argue that the "average developer" has probably never used SSH, or so rarely that it's practically as if they don't know what it is beyond a way to type commands into a remote machine. Think FTP. That is something that would be a little safer to assume that an "average developer" would have.

I have to consciously remember that a lot of the development tools I use on a day-to-day basis (ssh, git, emacs, rails, django, js unit testing, diff, etc), while commonly discussed on HN, are not actually the norm in "the rest of the world".

FTPing a pile of PHP files, versioned using .zip files, and merged by hand without diff tools seems to be the "average developer" when I start looking around a bit.


The real added value from Github is not Git support per se. It is the knowledge that you won't need to do what the author is about to do; maintain one more service by yourself.

It's not that it is a particularly daunting task, so isn't maintaining your own mail server, mailing list, NAS, blog... But it piles up, and at the end of the day you're probably better off not wasting your time supporting things that other people can do well enough (and probably cheaper).


Not that I'm against compatibility or that I'm in love with Github, but what about having one place where you track most/all of your OSS project of interest? Integrated issue tracker? Ability to collaboratively work with people across the planet with line by line comments? The value of having entire communities completely familiar with a common platform to collaborate on?

Github can and should further improve its relevance while becoming increasingly compatible and just right. But I fail to see how whipping up a self operated server replaces all of that.

I don't even want to mention backups, security updates, power interruptions...


I've been using github side by side with self-hosted git repositories for years and I've yet to notice github doing anything to my git repositories which makes them harder to use outside github. Am I missing something, or is this article just FUD?


The article is a bit mixed. The valid complaint of pull requests v. send-email is fairly important. The rest of the complaints aren't well thought out, and seem to be pure whinging.


That title is misleading... I expected blood!

About the post itself: I personally use github as a git host of public code only, other than viewing code (which does a great job at, IMO) and hosting I have no other use for it.

All the other things I do them with the cli.


How is pull-requests in github different from e.g. tasks in gmail? If you use the gmail task feature, I believe you are unable to access it via IMAP or from your mail client either. Or perhaps the filter options in gmail too? (can you sync these easily with procmail?). I don't use it much, but some of the google-plus integration might also go beyond simple email...

I think there must be other examples of unique features that gmail offers over email.

That being said, if I continue to look at the email as an analogy, look at what's happening with facebook. They removed the subject line, gave people facebook.com address, built their own messenger app, all seems to work quite well, with many of my friends stopping to use email and rely solely on facebook messages. Sure, it sends you an email, but effectively obscures your email address from your friends... I think this is worrying, and I can understand at least some of the sentiment of the author about github implementing a feature that people like, use and depend on, but one that is essentially incompatible or draws away from git.


Can someone explain to me why these articles are so popular here? They are always subjective, reflect a single viewpoint and are typically decorated rants - yet for some reason they constantly appear. Why?


Because this website is awful and full of drama queens.


LEAVE HACKERNEWS ALONE!


He's got a valid complaint mixed in with emotion and opinion. The valid complaint means you can't dismiss it out of hand, but the emotion and opinion mean that the comments get out hand.


No, he's got a complaint, verifying the "valid" part requires digging into what he wrote and really thinking about it. The emotion and opinion part makes readers not want to do that. But yeah, it doesn't help the comments either. :(


If you are leaving github and self-hosting, check out http://gitlabhq.com/ -- still has some rough edges, but getting better fast.

Fine grained permissions as well.


Valid complaint. I felt this exact way when I first started using github 2 years ago, and I almost didn't use it because of that.

But everyone is on github. It won. Even if the article makes 100% valid points, that won't change anytime soon, and until then, I'll be on github. And despite the problems mentioned, it is still an awesome free service.


OP isn't the only one who feels this way: http://www.wired.com/wiredenterprise/2012/05/torvalds_github...


I think the author's personal feelings towards Github the company are blinding them to logic:

> They do not improve or contribute to git itself (edit: as pointed out on HN, many individual employees at github are git contributors - but none seem to do so under the auspices of github, and the most prolific were contributors well before github came into being)

Sure...by hiring prolific Git contributors, and allowing them to continue to work on the product, they display their disdain for raw Git, because they didn't make them use a company account.


I agreed with most of the article, but the last paragraph is really silly: "ultimately, services like github and sourceforge are just fads, with very little (I think no) added value."


related HN discussion : Linus Torvalds won't do github pull requests

http://news.ycombinator.com/item?id=3960876


Funny post… Github is built on git. Usually whoever is running a project sets up the protocols for contributing. So any confusion over the send-email versus pull-request is a bit over blown. I have watched experienced devs struggle to come to terms with Git. Github makes the transition easier. Then piece by piece they investigate how to use Git properly.

Why do these posts show up after major funding happens. Is it because Github is now not the plucky underdog?


IM assuming this rant is about public open source repos that allow users to submit pull requests. Reason I say that is because I've used git for years with numerous teamsall of which used a bit repo. We had no issues you speak of. We never logged into the WebUI to do anything other than admin of adding users or keys.


Funny, I had no clue git even existed - I thought Github was Git. Honestly, I don't really care if Github follows the git protocol, it makes version control so painless and easy to use. Setting it up manually is tedious and time consuming. So in short, it solves a pain for me. That's all that matters.


This is why I always use Bitbuekt. As far as I am concerned, I dislike Linus so I won't use git. Well, I still use Linux because it's a great software, but git? Nah. Stick with Mercurial myself. No wonder why Python and Django and Python stick to Bitbucket lol


The author makes It sound like Github actively prevents him from using git://github... as a simple remote:

> Self-hosting is easy and cheap, I easily collaborate with people who prefer other solutions, and pushes take a quarter of a second.


Actually, why isn't there a git extension for github tasks? Theres no reason why I shouldn't be able to do git send-github gitusername <branch> and have it pop up a commit editor to type the pull request text, etc.



But that's not an extension. It could easily be. The fact that it isn't, and Defunkt's suggestion to alias hub to git nicely illustrates the original author's point.


Its not an extension, but close enough. I cannot upvote you enough.


> As far as marketing goes, git has effectively become git, just as search became google.

I think this should be:

> As far as marketing goes, git has effectively become github, just as search became google.


To be honest, the only reason I am still using GitHub is because it's by far the easiest way for me to show my work to potential employers.


I just discovered the git note command. To add to the article github could have used that for their commit comments, or do they?


I think of github more in terms of a foundation than a fad. Something that ought to last throughout time and forever.


Let me guess... you are a LEX & YACC fan!




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: