13 ms·

Go is moving to GitHub

686 points by davecheney 12y ago

virtue3 12y ago
Does anyone know what code review system they are using with github?
- ImJasonH 12y ago
  "We will use a Google-hosted instance of Gerrit for code reviews."
  - virtue3 12y ago
    thank you. Missed that in the article (was skimming >_> )
    - melvinmt 12y ago
      Me too, my brain is wired to read Gerrit as a common Dutch first name, so I thought he was talking about a person named Gerrit.
      - enneff 12y ago
        It is! Gerrit (our new code review system) is named after Gerrit Rietveld (the designer), as it Rietveld (our old code review system).
  - jacquesm 12y ago
    It lives here: https://code.google.com/p/gerrit/ https://code.google.com/p/gerrit/
- justinsb 12y ago
  They say it's Gerrit
- tkrajcar 12y ago
  I'm curious what Gerrit gets them that Github doesn't have natively, too.
  - pwnna 12y ago
    Gerrit works well for a project that has many different repositories, as you can do code review all in one screen. I did some CyanogenMod development and I really liked gerrit, albeit its poor performance on Firefox (client side app that had weird JS freezes in fx only..)
  - bradfitz 12y ago
    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.
    - Locke1689 12y ago
      If any of the other ones are public, which did you like best? IIRC, Mondrian was good, but not great.
      - bradfitz 12y ago
        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.
        piotrkaminski 12y ago
        In case you do want to try out another one at some point, I built https://reviewable.io https://reviewable.io to take some of my favorite features from Google's internal tool but integrate seamlessly with GitHub.
- _prometheus 12y ago
  Hm, I agree that github CR is not good. Glaf they're using Issues though as Github discussions are a _really nice_ way to build software. I personally find Gerrit painful to use, but has critical features, as enneff described. Hope Github really steps up to the plate. Also, everyone who uses github whould really check out *Sourcegraph's code review stuff. They show you really useful things like: - exactly what definitions were added/removed/changed (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.pulls/177/defs. https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...) - a diff with jump-to-definition links (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.pulls/177/files https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...) - a list of people and projects impacted by the change (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.pulls/177/impact https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...) Totally gets rid of the "understanding the PR diff" problem others mentioned
- RoyalGecko 12y ago
  Check out http://review.ninja http://review.ninja
jeffreyrogers 12y ago
It is great to see so many projects moving to git and GitHub in particular. GitHub is incredibly helpful for quickly taking a look at a project and figuring out what areas of a project are still evolving and being actively developed.
- negated 12y ago
  You could also say that everyone moving to GitHub is leading to a dangerous centralized monoculture that evaluates software quality based on how well it fits GitHub's conventions.
  - andrewchambers 12y ago
    git is still git - people don't even need a github account to have full functionality.
    - icebraining 12y ago
      How many Github projects accept git format-patch submissions? There's functionality beyond the basic DVCS commands.
      - dsymonds 12y ago
        In Go's case, we will be using Gerrit (elsewhere) for accepting submissions. GitHub will only be used as a source code mirror, wiki and issue tracker.
        NateDad 12y ago
        Wait wait wait... no pull requests? There's no way you could just hook up PR's to gerrit? Using github just as a mirror seems to defeat the entire purpose of github, which is to encourage more community members to contribute.
  - yohanatan 12y ago
    See: https://news.ycombinator.com/item?id=8605321 https://news.ycombinator.com/item?id=8605321
deleted 12y ago
[deleted]
mholt 12y ago
This is a huge compliment to GitHub, for Google to be moving one of its premier open source projects off of Google Code and onto GitHub. More importantly, though, this is a significant compliment to the Go community, for Go to uproot itself and move to where the majority of its users are.
- fleaflicker 12y ago
  They moved many of their popular Java projects recently: guava, guice, closure tools, gson.
yohanatan 12y ago
Which will have no bearing on the case of Go. Go has already been relegated to the bottom of the quality bin for my purposes by its designer(s)' ignorance of the last 30 years of type system research and hostility towards the functional style. See: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSCHS0 https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC...
- dsymonds 12y ago
  I think you mean s/ignorance/rejection/.
  - yohanatan 12y ago
    Probably a combination of both really. I get the sense that the 'Commander' hasn't done the requisite reading.
    - dsymonds 12y ago
      I just asked him in person. He has.
      - yohanatan 12y ago
        Only if you are inside the cult could you possibly believe that. Do you also think that Jim Jones was an expert on the New Testament teachings? If you take his word for it, of course he was.
    - enneff 12y ago
      Anyone that knows Rob will tell you that you're simply wrong about this.
      - yohanatan 12y ago
        Only if you are inside the cult could you possibly have that opinion. Do you also think that Jim Jones was an expert on the New Testament teachings? If you take his word for it, of course he was.
stephenitis 12y ago
Props on the move, it shows that golang is flexible to make moves for what's best for the community rather than stick it out in google code. I hope this results in benefits to the iteration cycle.
xkarga00 12y ago
I was hoping for this transition for a long time! Github is far more accessive and user-friendly than the Google repositories. Great move.
yid 12y ago
The writing's on the wall for Google Code. I don't think I've seen a new feature in several years.
- john2x 12y ago
  I hope they at least keep it in read-only mode. Oh god, all those dead links.
- ch4s3 12y ago
  I'd love for them to just go read only, a TON of academic work lives on there, but its awful to use.
  - kyrra 12y ago
    I much prefer Google code defect tracker to the GitHub one. But that's about the only plus of Google code. (Though, a small part of me wants mercurial to live on, but it doesn't seem like that will happen)
    - ch4s3 12y ago
      That defect tracker is nice. I've never used mercurial so I can't comment on that. Github keeps getting better, I'll bet if people asked for improvements to defect tracking we might get them.
- staunch 12y ago
  Google Code = Google Video GitHub = YouTube
  - DannyBee 12y ago
    Uh, no. Google Code took over the space in a way Google Video never did.
    - munificent 12y ago
      SourceForge -> Friendster Google Code -> MySpace GitHub -> Facebook :)
bbx 12y ago
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'm impressed.
- shurcooL 12y ago
  They've really made it easier to collaborate. Their website design is beautiful, consistent, making it delightful to use everyday. They fix issues quickly, are reliable, and have top notch customer support. They try to be at the top of their game and offer features to make our work easier (while maintaining simplicity, similar to Go). You can edit posts to fix typos, and GitHub Flavored Markdown is efficient to write. They have the best API and docs I've come across. It helps that once you're familiar with the workflow, if another project you want to make a contribution to on GitHub, it's super convenient (unlike in the past, think SourceForge and others). Even if you're not, the web flow makes it easy to press edit and go from there.
  - chrisconroy 12y ago
    You must have dealt with a completely different company and product. The public github is a lot better than the enterprise version at least in terms of stability. Still, both lack a lot of basic issue tracker and code review features. Github enterprise was a disaster with just a couple hundred users. Under the load of just a few hundred users it died almost every day. Their support team couldn't figure it out. We had to reboot the servers constantly. We begged them to add an option to reject force push to master. They refused. We ended up monkey patching their obscured source to add the feature, but it broke on upgrades and was hard to maintain. This is something probably every single customer of theirs wants, and it should take one engineer less than a day to implement. They only just added side by side diff support. IMHO this is a basic, core feature for any kind of code review workflow. I'm holding my breath for proper syntax highlighting while in diff view. We've since moved on to Atlassian Stash. While it isn't perfect, it's a dream compared to Github enterprise and a lot less $$$ to boot.
DigitalSea 12y ago
I think this is Google quietly admitting that Google Code is all but dead. They will not completely get rid of it, but I would not be surprised if they switch it to read only mode sometime soon. This is a momentous move for Github, especially with Microsoft moving .NET to Github as well. As someone who loves Github immensely, this makes me happy knowing that my favourite service is going to be around for a very long time. Kudos to the Github team for well and truly making it as the premier code hosting and collaboration tool for developers and lovers of open source. It only goes up from here.
- hosay123 12y ago
  Admitting Code is going nowhere, and seemingly for the first time in living memory, playing geek marketing catch-up with Microsoft :) I really love the new MS.
  - melling 12y ago
    As someone has already mentioned Google already has stuff on Github. Dart: https://github.com/dart-lang https://github.com/dart-lang And lots of other stuff: https://github.com/google https://github.com/google
    - Bahamut 12y ago
      Not limited to Google's main account, there is also Angular.js, Polymer, and CCA, to name a few others.
      - willnorris 12y ago
        CCA?
        Bahamut 12y ago
        Chrome Cordova Apps: https://github.com/MobileChromeApps/mobile-chrome-apps https://github.com/MobileChromeApps/mobile-chrome-apps
TheMagicHorsey 12y ago
Google Code has a really bad user interface. This migration makes sense. I wish they stuck with Mercurial and moved to Bitbucket instead, but Github is still better than Google Code.
- lxj 12y ago
  Google Code needs web and UX designers STAT, or it will die.
bigtunacan 12y ago
As someone who uses Ruby as my primary language; I'm totally jealous of this move. While there is a github mirror, it sucks having to use Subversion for the "one true repo" when everything else I work with these days is on git.
- tinco 12y ago
  I contributed to Ruby once by issueing a pull request to the GitHub mirror, it went fine. Is it less handy if you're a regular contributor?
  - bigtunacan 12y ago
    You can do pull requests through github, but Subversion is still preferred. Things aren't integrated; so for example if you look at https://github.com/ruby/ruby https://github.com/ruby/ruby you will notice Issues is not enabled; instead you have to go to a separate issue tracker over at https://bugs.ruby-lang.org/projects/ruby-trunk/issues https://bugs.ruby-lang.org/projects/ruby-trunk/issues. I still contribute, but the barrier to entry is higher; people have to hunt the ruby home page to find this information which is not ideal.
mwsherman 12y ago
I’m concerned that it won’t get any stars.
ChuckMcM 12y ago
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.
- arsenerei 12y ago
  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.
  - jpgvm 12y ago
    It has some hairy points though. I have never liked it's review per commit model (yes, I know you can circumvent this by using merge commits). I think the Github style works, assuming you have a sufficiently good CI system that can also receive GitHub web hooks.
- pnathan 12y ago
  Gerrit is very difficult to automate, I am told. You should take a careful look at it before jumping in. After farting with different SCM managers, I strongly believe that having raw ssh against directories is really the best way to deal with source code. (feel free to email me if you want a longer discussion... I'm at a conference and can't reply in detail now.)
Laremere 12y ago
I think this move is great for 2 big reasons: 1. This fits better with the workflows I know and are common for Go programmers. I use Github and Git regularly for a variety of things, and I only ever use Google Code and Mercurial for things dealing with the Go source or tool repositories. Along with the change of the much of the compiler source code from C to Go, this will make it a lot easier to get involved with the core of Go. 2. Simplifies using import paths for Go's tools. There's a bunch of different repositories in Google Code's Go project, and using them is slightly more painful because Go Get then requires mercurial to work. Reducing developer friction is a good thing, especially in odd places such as when a github repository uses a Google code repository and suddenly you need mecurial to import something using git.
sandGorgon 12y ago
It is so sad that Google Code has not been given some love. Their bug tracker is far, far superior to Github. The review mechanism is also quite, quite good (Gerrit I presume). The UX was too, too Sourceforge-ish and could not compete with Github or (what I think is best of breed) Bitbucket.
tsmarsh 12y ago
I guess its official, misogyny is ok in our industry. Have we forgotten about: http://lmgtfy.com/?q=github+misogyny http://lmgtfy.com/?q=github+misogyny ? I'm not sure github even experienced a dip in traffic. There are github alternatives, it took me 30 minutes to remove my github subscription and migrate my repos to bitbucket.
- Shizka 12y ago
  I will bite. How does using Github even remotely contribute to accepting misogyny in our industry?
  - Arnt 12y ago
    There was an ugly affair there. Github's handling of the affair is difficult to judge from outside. At least it seems that management's handling of this affair did not increase future misogyny at the company.
  - ta1976ta 12y ago
    I will bite back. Github's corporate culture appears to be very anti-woman. There is plenty of available evidence to this effect. There is very little apparent diversity (of any sort) in their large team. https://github.com/about/team https://github.com/about/team Using Github contributes to the success of this monoculture and encourages tech leaders to revere and duplicate this model. It makes tech more difficult for people outside of that group - the white, straight, male group. It makes tech culture worse. If I'm aware that you host on Github, I will make sure to consider what your competitors are doing before I use your service.
    - Shizka 12y ago
      I can see how you could make it a valid argument like that. Thanks for elaborating. Do you think that not using services from companies with a monoculture is the most effective way of furthering the cause? I'm all for more diversity in the technology and startup sector, but I do believe that the cause should, and eventually will, be solved by dialogue and focus on the issue - not by silently boycutting the companies. Or am I missing some part of the picture?
annnnd 12y ago
I think these are two separate issues: 1) Go is moving from Google Code to Github 2) Go is moving from Mercurial to Git To echo another user in the thread: "am I the only one who prefers Mercurial to Git?" In my view Mercurial is on par or even superior to Git, but lacks "Linus made it" fame. Too bad... I have used both Mercurial and Git and find hg command line interface much more intuitive to use. As for GUIs, there really isn't much difference between the two (too bad GitHub only supports git though).
- nbouscal 12y ago
  I get the impression that people who prefer Mercurial to Git only ever talk about interfaces and not about the underlying model. It seems to me that especially for a tool as important as version control, the underlying model is significantly more important: you can wrap a mediocre interface in a nice one, but if the model isn't very good you're pretty much stuck. That isn't to say that Mercurial's model is bad per se, but it certainly strikes me as significantly less elegant than Git's. (I'd be happy to find out I'm wrong about this - I know Git's model pretty intimately but am only moderately familiar with Mercurial's.) This problem seems to generalize quite a bit. Emphasis on surface-level characteristics rather than core differences seems to be prevalent in comparisons of databases, programming languages, web frameworks, etc. This seems quite bad, but I have no idea how to fix it.
  - kyrra 12y ago
    Not sure if it's better or not, but Mercurial has a concept called the RevLog[0]. A basic overview of it is here[1]. It sounds like the revlog format can become corrupted from time-to-time, but it's pretty rare now adays. [0] http://mercurial.selenic.com/wiki/RevlogNG http://mercurial.selenic.com/wiki/RevlogNG [1] http://ericsink.com/vcbe/html/repository_structure.html http://ericsink.com/vcbe/html/repository_structure.html EDIT: another blog explaining revlog format: http://gregoryszorc.com/blog/2014/02/05/the-mercurial-revlog/ http://gregoryszorc.com/blog/2014/02/05/the-mercurial-revlog...
  - rkangel 12y ago
    The underlying model is really not that different. There are some details that give rise to implementation differences, but Git and Mercurial have converged on a very similar approach. The reason that arguments about Git vs Mercurial tend to focus on the interface is because it's the only thing that's really different. You can do all the same thing with both tools. There are a couple of actual real differences: Mercurial's extension capability. Mercurial's named branch capability. How important they are is a matter of opinion. I find it interesting that Mercurial was hitorically missing some Git features, but they've all been added as extensions (shipped with the core Mercurial distro generally). That's not really something that's so do-able with Git.
Spitfire777 12y ago
Hi Go team, if you want an alternative for Gerrit code review, you can also use http://review.ninja http://review.ninja. It's also open source, so you are welcome to contribute. Cheers, Mitch
- skj 12y ago
  Took a brief look at the front page. - No side-by-side diffs? Didn't see any in screen shots. - The scopes asked for seem very broad. I may be confused, but it seemed like it was asking for write access to all repositories, public and private. I have access to several private repos (but I don't own them) for which this is unacceptable. If the scope is limited to the ones under github.com/me then it's not as big a deal... In any case, the scary scope list prevented me from experimenting.
  - Spitfire777 12y ago
    Hi skj! - What do you exactly mean by side-by-side diff? Currently you have diff view between the current HEAD of the Pull Request branch by the base commit. - Yes, that is true. This is a known issue mentioned by others and there is definitely a need to fix that. ReviewNinja comes from the GitHub Enterprise context, where you usually can trust the internal tool offering, that's why we kept it simple with the permissions in the first place. Thank you for the feedback!
    - skj 12y ago
      Here's a screenshot of some side-by-side diff action: https://fr.atlassian.com/wac/software/fisheye/overview/screenshot-tour/featureItems/0/featureItems/0/imageBinary/fisheye-side-by-side-diff.png https://fr.atlassian.com/wac/software/fisheye/overview/scree... Basically, it let's you look at the old code, or look at the new code, or see how they're different, all at the same time. Inline diffs (github-style) require you to keep a context as you scan through code, and it makes it harder to keep everything in your head.
- pridkett 12y ago
  Review Ninja is beautiful, but at it's core, it's just slightly more nice stuff on top of pull requests. It can't address the issues such as being able to edit someone else's pull request as part of a code review, can it?
sdegutis 12y ago
> The world today is quite different from the world then. Not really. Everyone used Git and Github 5 years ago too. That's why it was so annoying that Go chose to use Google Code for everything, although not surprising considering it's a Google project.
- DannyBee 12y ago
  "5 years ago too" No, they didn't. Github only started in April of 2008, or 6 years ago. Your implication is that they took over the world in a year. They didn't. I actually have seen the growth graphs of both before, and what you say is not even close to true.
- Laremere 12y ago
  Well, at the time of Go's open source announcement, Github was 1.5 years old. Go existed before that too, looking at the dates the first whiteboard doodles about what would become the Go programming language were done about a month before Github development started. Yes, Github was starting to thrive when Go was announced, but you could hardly say it had proven itself as much as it has now.

686 points by davecheney 12y ago

virtue3 12y ago

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

ImJasonH 12y ago
"We will use a Google-hosted instance of Gerrit for code reviews."
- virtue3 12y ago
  thank you. Missed that in the article (was skimming >_> )
  - melvinmt 12y ago
    Me too, my brain is wired to read Gerrit as a common Dutch first name, so I thought he was talking about a person named Gerrit.
    - enneff 12y ago
      It is! Gerrit (our new code review system) is named after Gerrit Rietveld (the designer), as it Rietveld (our old code review system).
- jacquesm 12y ago
  It lives here: https://code.google.com/p/gerrit/ https://code.google.com/p/gerrit/
justinsb 12y ago
They say it's Gerrit
tkrajcar 12y ago
I'm curious what Gerrit gets them that Github doesn't have natively, too.
- pwnna 12y ago
  Gerrit works well for a project that has many different repositories, as you can do code review all in one screen. I did some CyanogenMod development and I really liked gerrit, albeit its poor performance on Firefox (client side app that had weird JS freezes in fx only..)
- bradfitz 12y ago
  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.
  - Locke1689 12y ago
    If any of the other ones are public, which did you like best? IIRC, Mondrian was good, but not great.
    - bradfitz 12y ago
      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.
      - piotrkaminski 12y ago
        In case you do want to try out another one at some point, I built https://reviewable.io https://reviewable.io to take some of my favorite features from Google's internal tool but integrate seamlessly with GitHub.
_prometheus 12y ago
Hm, I agree that github CR is not good. Glaf they're using Issues though as Github discussions are a _really nice_ way to build software. I personally find Gerrit painful to use, but has critical features, as enneff described. Hope Github really steps up to the plate. Also, everyone who uses github whould really check out *Sourcegraph's code review stuff. They show you really useful things like: - exactly what definitions were added/removed/changed (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.pulls/177/defs. https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...) - a diff with jump-to-definition links (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.pulls/177/files https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...) - a list of people and projects impacted by the change (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.pulls/177/impact https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...) Totally gets rid of the "understanding the PR diff" problem others mentioned
RoyalGecko 12y ago
Check out http://review.ninja http://review.ninja

jeffreyrogers 12y ago

It is great to see so many projects moving to git and GitHub in particular. GitHub is incredibly helpful for quickly taking a look at a project and figuring out what areas of a project are still evolving and being actively developed.

negated 12y ago
You could also say that everyone moving to GitHub is leading to a dangerous centralized monoculture that evaluates software quality based on how well it fits GitHub's conventions.
- andrewchambers 12y ago
  git is still git - people don't even need a github account to have full functionality.
  - icebraining 12y ago
    How many Github projects accept git format-patch submissions? There's functionality beyond the basic DVCS commands.
    - dsymonds 12y ago
      In Go's case, we will be using Gerrit (elsewhere) for accepting submissions. GitHub will only be used as a source code mirror, wiki and issue tracker.
      - NateDad 12y ago
        Wait wait wait... no pull requests? There's no way you could just hook up PR's to gerrit? Using github just as a mirror seems to defeat the entire purpose of github, which is to encourage more community members to contribute.
- yohanatan 12y ago
  See: https://news.ycombinator.com/item?id=8605321 https://news.ycombinator.com/item?id=8605321

deleted 12y ago

[deleted]

mholt 12y ago

This is a huge compliment to GitHub, for Google to be moving one of its premier open source projects off of Google Code and onto GitHub. More importantly, though, this is a significant compliment to the Go community, for Go to uproot itself and move to where the majority of its users are.

fleaflicker 12y ago
They moved many of their popular Java projects recently: guava, guice, closure tools, gson.

yohanatan 12y ago

Which will have no bearing on the case of Go. Go has already been relegated to the bottom of the quality bin for my purposes by its designer(s)' ignorance of the last 30 years of type system research and hostility towards the functional style. See: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSCHS0 https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC...

dsymonds 12y ago
I think you mean s/ignorance/rejection/.
- yohanatan 12y ago
  Probably a combination of both really. I get the sense that the 'Commander' hasn't done the requisite reading.
  - dsymonds 12y ago
    I just asked him in person. He has.
    - yohanatan 12y ago
      Only if you are inside the cult could you possibly believe that. Do you also think that Jim Jones was an expert on the New Testament teachings? If you take his word for it, of course he was.
  - enneff 12y ago
    Anyone that knows Rob will tell you that you're simply wrong about this.
    - yohanatan 12y ago
      Only if you are inside the cult could you possibly have that opinion. Do you also think that Jim Jones was an expert on the New Testament teachings? If you take his word for it, of course he was.

stephenitis 12y ago

Props on the move, it shows that golang is flexible to make moves for what's best for the community rather than stick it out in google code. I hope this results in benefits to the iteration cycle.

xkarga00 12y ago

I was hoping for this transition for a long time! Github is far more accessive and user-friendly than the Google repositories. Great move.

yid 12y ago

The writing's on the wall for Google Code. I don't think I've seen a new feature in several years.

john2x 12y ago
I hope they at least keep it in read-only mode. Oh god, all those dead links.
ch4s3 12y ago
I'd love for them to just go read only, a TON of academic work lives on there, but its awful to use.
- kyrra 12y ago
  I much prefer Google code defect tracker to the GitHub one. But that's about the only plus of Google code. (Though, a small part of me wants mercurial to live on, but it doesn't seem like that will happen)
  - ch4s3 12y ago
    That defect tracker is nice. I've never used mercurial so I can't comment on that. Github keeps getting better, I'll bet if people asked for improvements to defect tracking we might get them.
staunch 12y ago
Google Code = Google Video GitHub = YouTube
- DannyBee 12y ago
  Uh, no. Google Code took over the space in a way Google Video never did.
  - munificent 12y ago
    SourceForge -> Friendster Google Code -> MySpace GitHub -> Facebook :)

bbx 12y ago

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'm impressed.

shurcooL 12y ago
They've really made it easier to collaborate. Their website design is beautiful, consistent, making it delightful to use everyday. They fix issues quickly, are reliable, and have top notch customer support. They try to be at the top of their game and offer features to make our work easier (while maintaining simplicity, similar to Go). You can edit posts to fix typos, and GitHub Flavored Markdown is efficient to write. They have the best API and docs I've come across. It helps that once you're familiar with the workflow, if another project you want to make a contribution to on GitHub, it's super convenient (unlike in the past, think SourceForge and others). Even if you're not, the web flow makes it easy to press edit and go from there.
- chrisconroy 12y ago
  You must have dealt with a completely different company and product. The public github is a lot better than the enterprise version at least in terms of stability. Still, both lack a lot of basic issue tracker and code review features. Github enterprise was a disaster with just a couple hundred users. Under the load of just a few hundred users it died almost every day. Their support team couldn't figure it out. We had to reboot the servers constantly. We begged them to add an option to reject force push to master. They refused. We ended up monkey patching their obscured source to add the feature, but it broke on upgrades and was hard to maintain. This is something probably every single customer of theirs wants, and it should take one engineer less than a day to implement. They only just added side by side diff support. IMHO this is a basic, core feature for any kind of code review workflow. I'm holding my breath for proper syntax highlighting while in diff view. We've since moved on to Atlassian Stash. While it isn't perfect, it's a dream compared to Github enterprise and a lot less $$$ to boot.

DigitalSea 12y ago

I think this is Google quietly admitting that Google Code is all but dead. They will not completely get rid of it, but I would not be surprised if they switch it to read only mode sometime soon. This is a momentous move for Github, especially with Microsoft moving .NET to Github as well. As someone who loves Github immensely, this makes me happy knowing that my favourite service is going to be around for a very long time. Kudos to the Github team for well and truly making it as the premier code hosting and collaboration tool for developers and lovers of open source. It only goes up from here.

hosay123 12y ago
Admitting Code is going nowhere, and seemingly for the first time in living memory, playing geek marketing catch-up with Microsoft :) I really love the new MS.
- melling 12y ago
  As someone has already mentioned Google already has stuff on Github. Dart: https://github.com/dart-lang https://github.com/dart-lang And lots of other stuff: https://github.com/google https://github.com/google
  - Bahamut 12y ago
    Not limited to Google's main account, there is also Angular.js, Polymer, and CCA, to name a few others.
    - willnorris 12y ago
      CCA?
      - Bahamut 12y ago
        Chrome Cordova Apps: https://github.com/MobileChromeApps/mobile-chrome-apps https://github.com/MobileChromeApps/mobile-chrome-apps

TheMagicHorsey 12y ago

Google Code has a really bad user interface. This migration makes sense. I wish they stuck with Mercurial and moved to Bitbucket instead, but Github is still better than Google Code.

lxj 12y ago
Google Code needs web and UX designers STAT, or it will die.

bigtunacan 12y ago

As someone who uses Ruby as my primary language; I'm totally jealous of this move. While there is a github mirror, it sucks having to use Subversion for the "one true repo" when everything else I work with these days is on git.

tinco 12y ago
I contributed to Ruby once by issueing a pull request to the GitHub mirror, it went fine. Is it less handy if you're a regular contributor?
- bigtunacan 12y ago
  You can do pull requests through github, but Subversion is still preferred. Things aren't integrated; so for example if you look at https://github.com/ruby/ruby https://github.com/ruby/ruby you will notice Issues is not enabled; instead you have to go to a separate issue tracker over at https://bugs.ruby-lang.org/projects/ruby-trunk/issues https://bugs.ruby-lang.org/projects/ruby-trunk/issues. I still contribute, but the barrier to entry is higher; people have to hunt the ruby home page to find this information which is not ideal.

mwsherman 12y ago

I’m concerned that it won’t get any stars.

ChuckMcM 12y ago

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.

arsenerei 12y ago
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.
- jpgvm 12y ago
  It has some hairy points though. I have never liked it's review per commit model (yes, I know you can circumvent this by using merge commits). I think the Github style works, assuming you have a sufficiently good CI system that can also receive GitHub web hooks.
pnathan 12y ago
Gerrit is very difficult to automate, I am told. You should take a careful look at it before jumping in. After farting with different SCM managers, I strongly believe that having raw ssh against directories is really the best way to deal with source code. (feel free to email me if you want a longer discussion... I'm at a conference and can't reply in detail now.)

Laremere 12y ago

I think this move is great for 2 big reasons: 1. This fits better with the workflows I know and are common for Go programmers. I use Github and Git regularly for a variety of things, and I only ever use Google Code and Mercurial for things dealing with the Go source or tool repositories. Along with the change of the much of the compiler source code from C to Go, this will make it a lot easier to get involved with the core of Go. 2. Simplifies using import paths for Go's tools. There's a bunch of different repositories in Google Code's Go project, and using them is slightly more painful because Go Get then requires mercurial to work. Reducing developer friction is a good thing, especially in odd places such as when a github repository uses a Google code repository and suddenly you need mecurial to import something using git.

sandGorgon 12y ago

It is so sad that Google Code has not been given some love. Their bug tracker is far, far superior to Github. The review mechanism is also quite, quite good (Gerrit I presume). The UX was too, too Sourceforge-ish and could not compete with Github or (what I think is best of breed) Bitbucket.

tsmarsh 12y ago

I guess its official, misogyny is ok in our industry. Have we forgotten about: http://lmgtfy.com/?q=github+misogyny http://lmgtfy.com/?q=github+misogyny ? I'm not sure github even experienced a dip in traffic. There are github alternatives, it took me 30 minutes to remove my github subscription and migrate my repos to bitbucket.

Shizka 12y ago
I will bite. How does using Github even remotely contribute to accepting misogyny in our industry?
- Arnt 12y ago
  There was an ugly affair there. Github's handling of the affair is difficult to judge from outside. At least it seems that management's handling of this affair did not increase future misogyny at the company.
- ta1976ta 12y ago
  I will bite back. Github's corporate culture appears to be very anti-woman. There is plenty of available evidence to this effect. There is very little apparent diversity (of any sort) in their large team. https://github.com/about/team https://github.com/about/team Using Github contributes to the success of this monoculture and encourages tech leaders to revere and duplicate this model. It makes tech more difficult for people outside of that group - the white, straight, male group. It makes tech culture worse. If I'm aware that you host on Github, I will make sure to consider what your competitors are doing before I use your service.
  - Shizka 12y ago
    I can see how you could make it a valid argument like that. Thanks for elaborating. Do you think that not using services from companies with a monoculture is the most effective way of furthering the cause? I'm all for more diversity in the technology and startup sector, but I do believe that the cause should, and eventually will, be solved by dialogue and focus on the issue - not by silently boycutting the companies. Or am I missing some part of the picture?

annnnd 12y ago

I think these are two separate issues: 1) Go is moving from Google Code to Github 2) Go is moving from Mercurial to Git To echo another user in the thread: "am I the only one who prefers Mercurial to Git?" In my view Mercurial is on par or even superior to Git, but lacks "Linus made it" fame. Too bad... I have used both Mercurial and Git and find hg command line interface much more intuitive to use. As for GUIs, there really isn't much difference between the two (too bad GitHub only supports git though).

nbouscal 12y ago
I get the impression that people who prefer Mercurial to Git only ever talk about interfaces and not about the underlying model. It seems to me that especially for a tool as important as version control, the underlying model is significantly more important: you can wrap a mediocre interface in a nice one, but if the model isn't very good you're pretty much stuck. That isn't to say that Mercurial's model is bad per se, but it certainly strikes me as significantly less elegant than Git's. (I'd be happy to find out I'm wrong about this - I know Git's model pretty intimately but am only moderately familiar with Mercurial's.) This problem seems to generalize quite a bit. Emphasis on surface-level characteristics rather than core differences seems to be prevalent in comparisons of databases, programming languages, web frameworks, etc. This seems quite bad, but I have no idea how to fix it.
- kyrra 12y ago
  Not sure if it's better or not, but Mercurial has a concept called the RevLog[0]. A basic overview of it is here[1]. It sounds like the revlog format can become corrupted from time-to-time, but it's pretty rare now adays. [0] http://mercurial.selenic.com/wiki/RevlogNG http://mercurial.selenic.com/wiki/RevlogNG [1] http://ericsink.com/vcbe/html/repository_structure.html http://ericsink.com/vcbe/html/repository_structure.html EDIT: another blog explaining revlog format: http://gregoryszorc.com/blog/2014/02/05/the-mercurial-revlog/ http://gregoryszorc.com/blog/2014/02/05/the-mercurial-revlog...
- rkangel 12y ago
  The underlying model is really not that different. There are some details that give rise to implementation differences, but Git and Mercurial have converged on a very similar approach. The reason that arguments about Git vs Mercurial tend to focus on the interface is because it's the only thing that's really different. You can do all the same thing with both tools. There are a couple of actual real differences: Mercurial's extension capability. Mercurial's named branch capability. How important they are is a matter of opinion. I find it interesting that Mercurial was hitorically missing some Git features, but they've all been added as extensions (shipped with the core Mercurial distro generally). That's not really something that's so do-able with Git.

Spitfire777 12y ago

Hi Go team, if you want an alternative for Gerrit code review, you can also use http://review.ninja http://review.ninja. It's also open source, so you are welcome to contribute. Cheers, Mitch

skj 12y ago
Took a brief look at the front page. - No side-by-side diffs? Didn't see any in screen shots. - The scopes asked for seem very broad. I may be confused, but it seemed like it was asking for write access to all repositories, public and private. I have access to several private repos (but I don't own them) for which this is unacceptable. If the scope is limited to the ones under github.com/me then it's not as big a deal... In any case, the scary scope list prevented me from experimenting.
- Spitfire777 12y ago
  Hi skj! - What do you exactly mean by side-by-side diff? Currently you have diff view between the current HEAD of the Pull Request branch by the base commit. - Yes, that is true. This is a known issue mentioned by others and there is definitely a need to fix that. ReviewNinja comes from the GitHub Enterprise context, where you usually can trust the internal tool offering, that's why we kept it simple with the permissions in the first place. Thank you for the feedback!
  - skj 12y ago
    Here's a screenshot of some side-by-side diff action: https://fr.atlassian.com/wac/software/fisheye/overview/screenshot-tour/featureItems/0/featureItems/0/imageBinary/fisheye-side-by-side-diff.png https://fr.atlassian.com/wac/software/fisheye/overview/scree... Basically, it let's you look at the old code, or look at the new code, or see how they're different, all at the same time. Inline diffs (github-style) require you to keep a context as you scan through code, and it makes it harder to keep everything in your head.
pridkett 12y ago
Review Ninja is beautiful, but at it's core, it's just slightly more nice stuff on top of pull requests. It can't address the issues such as being able to edit someone else's pull request as part of a code review, can it?

sdegutis 12y ago

> The world today is quite different from the world then. Not really. Everyone used Git and Github 5 years ago too. That's why it was so annoying that Go chose to use Google Code for everything, although not surprising considering it's a Google project.

DannyBee 12y ago
"5 years ago too" No, they didn't. Github only started in April of 2008, or 6 years ago. Your implication is that they took over the world in a year. They didn't. I actually have seen the growth graphs of both before, and what you say is not even close to true.
Laremere 12y ago
Well, at the time of Go's open source announcement, Github was 1.5 years old. Go existed before that too, looking at the dates the first whiteboard doodles about what would become the Go programming language were done about a month before Github development started. Yes, Github was starting to thrive when Go was announced, but you could hardly say it had proven itself as much as it has now.