Live data from Hacker News

Go is moving to GitHub

groups.google.com

221–230 of 244 posts

Re: Go is moving to GitHub

#221

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

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?

Hi pridkett!

Anything pushed to the branch of a pull request is an edit on the pull request. Once something new is pushed on to the pull request, the voting in ReviewNinja needs to be repeated.

Furthermore, Issues linked to a commit will be linked to all new commits by Review.Ninja automatically, as long as the issue isn't solve. You only merge, once all issues are solved / it is save to merge.

Cheers, Mitch

Re: Go is moving to GitHub

#222
post #168

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, ther…

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…

hg has a very elegant underlying data model, which you wind up not having to care about at all (a nice property of a good abstraction), unlike git.

:)

I use hg for almost all my own software development, and it's a great pleasure. I've also used hg professionally in both development and support modes, and if/when I ever get around to starting my own software business, hg or other "safe by default" system will be enforced with an iron fist. It's quite a lot better than git.

Re: Go is moving to GitHub

#223
post #157

Earlier quoted context omitted.

I will bite. How does using Github even remotely contribute to accepting misogyny in our industry?

Github promoted misogyny internally. You give them revenue, allowing them to continue to run their business. Ergo, you are promoting the misogyny Github promotes* internally. * The burden of proof that Github doesn't promote misogyny is on Github. EDIT: I personally use Github, but I cancelled my account after what happened. For new projects I use bitbucket. I actually feel bad when I'm using Github precisely because…

I might be wrong but isn't that a faulty argument. That's the same as saying that you pay tax in the US(or any other counter) and you therefore condone of all the behavior of said country? Or saying that if you use any Google product you promote corporate monopoly? There's quite a way from paying for a service such as Github to promoting misogyny.

Re: Go is moving to GitHub

#224
post #208
post #98

Earlier quoted context omitted.

That was canceled due to a patent lawsuit. It would have cost apple a ton of money to pay a patent troll to be able to open source FaceTime. http://www.bbc.co.uk/news/technology-20236114

To clarify. Because of this lawsuit, Apple moved facetime away from being peer-to-peer to now being routed through Apple's servers. Since they have to use the centralized model, opening up the protocol for others to use would also require using Apple's servers to play nicely. So Apple would be footing the bill.

Thanks; it's just a present irritant because the Hangouts client for iPad is presently broken (no video), and Skype doesn't support video conference calls in their tablet clients, so I don't have a free cross-platform multi-way tablet-based video-chat protocol that works, and another entry in that space would be convenient.

Re: Go is moving to GitHub

#225

Earlier quoted context omitted.

Another monopoly in the making: "github cuz everyone is on github".

"facebook 'cause everyone is on facebook." It's the same effect. There are only two things that are going to fix it - either something amazingly better comes along (facebook vs myspace) or the incumbent royally screws up (reddit vs digg).

To be fair, it's not entirely the same sort of thing. Git is an open protocol. Github just happens to be one of many sites hosting git repositories. Moving a repository to another host is trivial; you already have all the data in your local tree.

Facebook, on the other hand, is one of a kind. I absolutely must have an account there if I want to do anything Facebook. And good luck getting your data out or interoperating with other social networks.

Re: Go is moving to GitHub

#226
post #140

Earlier quoted context omitted.

A bit OT, but probably the biggest roadblock for me switching over to Go is the wonky syntax. Are there any plans to make Go more accessible to someone coming from more traditional languages? (i.e. like "do" notation in Haskell) I've done the Go tutorial about 5 times last I checked (seriously), and I just can't stomach the syntax. I may be tainted by my years of C, though.

What?! If anything, your use of C should make Go's syntax really familiar (aside from putting the name before the type, which doesn't take long to get used to). It's exactly like any other C-like imperative language. C, C++, Java, C#, even Javascript. Those are pretty traditional langauges. Haskell is not what I think most people would call a "traditional language". What exactly is your problem with the syntax?

My point about Haskell was not to say that it was more intuitive for imperative programmers, rather, it was to demonstrate a syntactic sugar construct that eases programmers in. Because Go's syntax is so similar to C, it is confusing because as a coder, I can only context switch a finite amount of times.

Re: Go is moving to GitHub

#228

Earlier quoted context omitted.

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…

If they wanted to they could turn Google Code into a real competitor for Github with full GAE and Compute integration. That would make it an amazing platform.

Who says they won't? :)

Seriously though, yes, that would be really cool, but probably not something you could directly transform google code into. Google Code is a pretty legacy codebase in a lot of ways. It would likely require making a new platform to do such a thing.

Re: Go is moving to GitHub

#229

> 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.

"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.

Re: Go is moving to GitHub

#230

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 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.)

Post reply on HN