Live data from Hacker News

Go is moving to GitHub

groups.google.com

111–120 of 244 posts

Re: Go is moving to GitHub

#111

Now all we need is Jeff Bezos to buy Github :-) That would be funny. But on the story this is a great move, Github is much nicer than Google Code and more actively supported. I had not heard of Gerrit before and that was a really pleasant discovery. Now to figure out how to get that setup at the office.

Gerrit is an absolute treasure of a tool. I shudder everytime I make a pull request in Github because Gerrit's contribution model is so much better for my workflow.

Re: Go is moving to GitHub

#113
post #45

Google hosting Go on GitHub. Microsoft hosting .NET on GitHub. It must feel like an accomplishment to be implicitly endorsed by these companies. Considering open source's history, you'd think its primary management tool would be open source as well. I guess it's GitHub's combination of accessible design + performant version control + lack of ads + reliability that made it the premium source for anything open source.…

It's a really great collaboration tool. I think git itself could use some work in certain ways, but Github really makes it hard to go to any other web-based version control + pull request type tools.

Re: Go is moving to GitHub

#114
post #68

Earlier quoted context omitted.

I think Google stopped bothering with Google Code when Github came to popularity. Google Code doesn't really fill Google's mission, so it's not absurd for them not to bother once someone who's truly focused on the space has created a superior competitor.

Google Code was created mainly to combat the monoculture of Sourceforge, which was slowly growing crappier. Google wanted to create a place open source people actually wanted to be, and had reliable hosting, instead of a place people had to sadly live with that was pretty unreliable (no offense meant to my friends at sourceforge). Doing so jump started some competition in this space. While github is slowly becoming a…

Hi Dan! Remember when I DDOSed Google Code on Super Tuesday 2008, when I thought it would be a good idea to host my election map result tiles there, and then I forgot to turn off the cachebuster in my tile URLs? Good times... :-)

Re: Go is moving to GitHub

#115

Earlier quoted context omitted.

Go team member here. I've used five different code review tools, and Github is the worst of the five. I regularly bug them (Github) about this, and they know it. I hear rumors they've been working on it a lot. Github's review mechanisms barely scratch the surface of what's possible.

If any of the other ones are public, which did you like best? IIRC, Mondrian was good, but not great.

From best to worse, in my experience:

1) Google's current internal one

2) Gerrit (open source, to be used by Go)

3) Google's old one (Mondrian)

4) Rietveld (open source, but run for free at codereview.appspot.com)

5) Github

I would totally suspect that Phabricator or Review Board would be well above Github (as are 1-4 in my list), but I don't know where. I have little desire to use or explore new code review systems at this point. Four per day is enough for me at the moment.

Re: Go is moving to GitHub

#116
post #19

Earlier quoted context omitted.

I'm curious what Gerrit gets them that Github doesn't have natively, too.

There are a lot of things lacking about GitHub's code review process (pull requests). Off the top of my head: - Merging a pull request (almost) always creates a merge commit, polluting the change history. Gerrit will automatically rebase the changes atop the master branch head, leaving a nice linear history. - Pull requests require the contributor to create a public fork of the repository they're committing to. I can…

This is a fantastic answer on Github's (rare) shortcomings. I hope the Github team is here reading this and taking notes!

Re: Go is moving to GitHub

#117
post #62
post #53

Earlier quoted context omitted.

I'm really curious to give Gerrit a try. Is it like the existing Rietveld system used for Go? - I've been using the "apply mail" flow to avoid merge commits and to squash commits when appropriate (based on Nathaniel Talbott's post http://blog.spreedly.com/author/ntalbott/#.VGVhz5PF_Zs ). It will be nice to have something automatic. - At least contributors with the commit bit can just create a feature branch and a pul…

We're going to build a bot that replies to pull requests to the Go core. It'll say "Sorry, we don't take pull requests, but here's how to use Gerrit [link]. Thanks!"

FYI if you have a "CONTRIBUTING" or "CONTRIBUTING.md" document at the project root, a neat little info bar "Please read the [contributing] guidelines before proceeding" will show up to anyone filing a bug or a PR.

Re: Go is moving to GitHub

#118
post #77
post #45

Google hosting Go on GitHub. Microsoft hosting .NET on GitHub. It must feel like an accomplishment to be implicitly endorsed by these companies. Considering open source's history, you'd think its primary management tool would be open source as well. I guess it's GitHub's combination of accessible design + performant version control + lack of ads + reliability that made it the premium source for anything open source.…

I agree. I almost think the name Git Hub is unfortunate at this point: they're doing something so right they could nearly invent their own VCS, use ESR's new tool, or even switch to hg/darcs/etc, and still gain momentum. The Go community seems to be hopping onto a fairly heavy pendulum.

The best-engineered technology rarely becomes the most popular. I think git has some huge problems, but now it's ubiquitous. Everyone has at least a basic knowledge of it, and that makes it the best technology. Switching to something else would be a step backward.

Re: Go is moving to GitHub

#119
post #2

Does anyone know what code review system they are using with github?

I'm curious what Gerrit gets them that Github doesn't have natively, too.

- GitHub doesn't show you what changed in a PR from the last time you looked at it. You can look through the individual commits, but this can be painful if there's a lot of them, and can easily become impossible if the code was merged, rebased, or squashed.

- GitHub sends each comment individually, encouraging "shotgun commenting" instead of a coherent set on the sender side, and leaving the receiver to deal with dozens of individual emails.

- GitHub attaches line comments to the deltas, which makes the comments disappear if the underlying code changes. This makes it easy to "lose" a comment during a review, and forget to check that something was fixed properly. Even if a comment survives, GitHub doesn't track (non-) resolution in any way, so it's still easy to forget to take care of stuff.

- You can't customize things: can't pick your favorite source code font, the wrapping margin, syntax highlighting colors (as it doesn't have syntax highlighting at all), links that open your editor directly on the correct line, etc.

As it happens, https://reviewable.io fixes all these, and has a much lighter-weight integration with GitHub than Gerrit does, not to mention a much friendlier UI. And yeah, it's my own project so I'm obviously biased, but check it out if you're annoyed with GitHub's code reviews but Gerrit/Phabricator are too heavy for your needs.

Re: Go is moving to GitHub

#120

Earlier quoted context omitted.

If any of the other ones are public, which did you like best? IIRC, Mondrian was good, but not great.

From best to worse, in my experience: 1) Google's current internal one 2) Gerrit (open source, to be used by Go) 3) Google's old one (Mondrian) 4) Rietveld (open source, but run for free at codereview.appspot.com) 5) Github I would totally suspect that Phabricator or Review Board would be well above Github (as are 1-4 in my list), but I don't know where. I have little desire to use or explore new code review systems…

In case you do want to try out another one at some point, I built https://reviewable.io to take some of my favorite features from Google's internal tool but integrate seamlessly with GitHub.
Post reply on HN