Leaving Github
bytbox.net
bytbox.net
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.
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.
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.
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.
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.
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.
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.
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.
And to your point, you cannot add files via github.
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":
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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
<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" /><base href="http://git.bytbox.net/ /> fixes that page, but pages reached from there are still suffering the some bad base href.
- 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 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.
I honestly believe Github is the best thing to happen to OSS in a long time.
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.
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.
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.
And, for those people, github offers an appliance that sits on your network.
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.
"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."
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).
"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.
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.
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.
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".
On the actual post: what prevents one from using `git am` locally and then pushing the changes to GitHub?
wtf?
Absolutely nothing. His entire 'Github vs Git' thesis is a false dichotomy.
How can you commit to the linux kernel using github's interface? I have not seen a button for `git send-email`.
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.
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.
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.
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.
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.
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.
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.
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.
And the original, "expert" workflow is still available for those who want it.
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.
If you click the "SSH" button on GitHub repositories, it'll remember your preference.
And thanks, now I know why only some repos ask for username/password.
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.
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.
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.
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.
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.)
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
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
ease of sending links to diff to non-technical people
that just want to see a text change was made, etc.
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.
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.
Horses for courses really :-)
Is this a joke ?
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.
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).
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...
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.
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.
Fine grained permissions as well.
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.
> 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.
Why do these posts show up after major funding happens. Is it because Github is now not the plucky underdog?
sounds like author swims in a specific contained pool that he believes is the only pool around. all the git command line commands still work; why not just use that?
> Self-hosting is easy and cheap, I easily collaborate with people who prefer other solutions, and pushes take a quarter of a second.
I think this should be:
> As far as marketing goes, git has effectively become github, just as search became google.