Live data from Hacker News

Go is moving to GitHub

groups.google.com

211–220 of 244 posts

Re: Go is moving to GitHub

#211

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…

Review Board isn't as good as it could be. Sometimes it's diffing tool provides far too much noise to be useful.

Re: Go is moving to GitHub

#212
post #157

Earlier quoted context omitted.

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

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

> There is very little apparent diversity (of any sort) in their large team.

I'll grant you that they all look the same. Doesn't prove much -- Karl Marx looked a lot like Andrew Carnegie.

Re: Go is moving to GitHub

#214
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.…

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

Re: Go is moving to GitHub

#215
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…

> This seems quite bad, but I have no idea how to fix it.

Most people, when interacting with their database, use SQL (or whatever native command language it provides), and don't need to worry about the underpinnings.

Most people, when interacting with their source code repository tool, use the command set provided by the tool and don't worry about the underpinnings.

I've had problems with my databases before that forced me to learn about the horrid can of worms underneath. Until I had these problems, I didn't care because it was entirely irrelevant to the thing I was trying to do.

I've thankfully never had enough of a problem with any of the repo tools I've used (cvs, svn, hg, git) that I needed to go diving into the data structure itself to figure out or fix a problem. I hope I never have to, because that's not the job I'm trying to do.

You shouldn't need to care how the tool works in order to use it, unless using it is your primary job. My primary job is writing code for my application, not writing code for my database or repo tool.

If going distributed, hg provides a much more sane initial set of commands that make more sense to people with experience using anything that isn't git. This matters a lot, because those commands are the only things most users ever really care about.

Re: Go is moving to GitHub

#216

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…

If they were smart about Google Code they would update it significantly and make it a competitor to Github with full GAE and Google Compute integration.

I'd be happy if they'd just let you turn off syntax highlighting for code blocks in the wiki. The default sh highlighter looks like crap if you display code in any unsupported language like assembly or Tcl.
 tags can be used but then you lose the gray background. That something so simple isn't implemented is the biggest sign of how abandoned Google Code has become.

Re: Go is moving to GitHub

#217
post #138

Earlier quoted context omitted.

Nice summary; thank you. I don't know why people put up with the merge commit pollution. Great to see Go taking the best of both worlds.

The merge history is the true one, it's what you want when browsing backwards to see how particular things changed. Rebase creates fake commits corresponding to a tree that never actually existed anywhere. Your history viewer should be able to linearize the tree for you if you want, but the canonical history in the repository should be the true one.

That's just one workflow.

For Go, we will require that contributors (everyone working on Go) prepare their commit at head (or at least make the commit able to be automatically rebased). It makes no sense to have a merge commit for every single commit. That would add no extra information and double the size of the commit log.

Re: Go is moving to GitHub

#219
post #197

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

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 dea…

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!

Re: Go is moving to GitHub

#220

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

How much do we have to bribe you for Bitbucket integration?

We will work for cookies! :) jk

We are very open for cool new ideas, features and also contributions on our GitHub repo: https://github.com/reviewninja/review.ninja

ReviewNinja comes from the GitHub Enterprise context (as we use GitHub Enterprise in our company) and we want to offer an open source code review tool for both GitHub.com and GitHub Enterprise.

Bitbucket is awesome! But I think if we want to support on premise installations with Review.Ninja, BitBucket support would be overkill.

Cheers, Mitch

Post reply on HN