Live data from Hacker News

Go is moving to GitHub

groups.google.com

131–140 of 244 posts

Re: Go is moving to GitHub

#131
post #62

Earlier quoted context omitted.

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

Not to be flippant, but if you are not going to use pull-requests, what is the benefit of moving to Github? Will you use the issue tracking system? If not then it just seems like switching to git using the present google code host would suffice from a technical viewpoint.

We will use the GitHub issue tracker, which will allow easy cross references between go issues and other projects on github.

Re: Go is moving to GitHub

#132

Earlier quoted context omitted.

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…

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…

    > Still, both lack a lot of basic issue tracker and code 
    > review features.
I strongly disagree. What you might consider "basic features" I'd consider antifeatures. The bare simplicity of the issue tracker is precisely why I use it for my (large) projects. The PR model of code review scales elegantly to hundreds of contributors. I'd be devastated to see GitHub's collaboration tools move even a step toward the hellscape that is JIRA.

Re: Go is moving to GitHub

#133

Earlier quoted context omitted.

What are gits huge problems and what other technology solves those? Not trying to put you on the spot, just curious.

IMO the main problem is that the command vocabulary is a mess. Do I need a soft, mixed or hard reset? Can I use "reset" to revert a single file, or do I need "checkout" for that? After years of using and loving git, this still confuses me. It's all logical in terms of git internals, but I'm not thinking in those terms when I want to revert something.

The "plumbing" is beautiful and the "porcelain" is a hideous mess.

Re: Go is moving to GitHub

#134

Earlier quoted context omitted.

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…

> Still, both lack a lot of basic issue tracker and code > review features. I strongly disagree. What you might consider "basic features" I'd consider antifeatures. The bare simplicity of the issue tracker is precisely why I use it for my (large) projects. The PR model of code review scales elegantly to hundreds of contributors. I'd be devastated to see GitHub's collaboration tools move even a step toward the hellsca…

I agree with that, but just to be clear, Stash is independent of Jira (though they do integrate) and has a simple pull request model. It's actually very nice to use (pretty much just like BitBucket).

Re: Go is moving to GitHub

#135
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 format that git stores it's data in is great, the tool most commonly used to access that data is a bit of a mess. So there's no reason not to use git with a different UI and there are a lot of UIs for git.

Re: Go is moving to GitHub

#136
post #10

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.

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.

Having migrated projects from GitHub to/from Bitbucket and internal git servers - which is a 10 minute job at most - I'm not terribly worried about this.

Re: Go is moving to GitHub

#137

Earlier quoted context omitted.

What are gits huge problems and what other technology solves those? Not trying to put you on the spot, just curious.

IMO the main problem is that the command vocabulary is a mess. Do I need a soft, mixed or hard reset? Can I use "reset" to revert a single file, or do I need "checkout" for that? After years of using and loving git, this still confuses me. It's all logical in terms of git internals, but I'm not thinking in those terms when I want to revert something.

And this will never get fixed so long as people keep denying there's a problem. Even when people want to fix stuff like this it's hard to transition well from where you are to where you want to be, but at the moment people seem to be able to use this poorly evolved interface daily without noticing these ridiculous and uneccesary inconsistancies.

Re: Go is moving to GitHub

#138
post #19

Earlier quoted context omitted.

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…

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.

Re: Go is moving to GitHub

#139

Earlier quoted context omitted.

Totally serious. And, it's not just the lack of generics-- that's just the tip of the iceberg.

What problems have the lack of generics caused you in development?

Last time I used a language without generics I had to cast web form values (we used a library with a general-purpose representation of "form control backed by object"). Sometimes these were incorrect, and had to be debugged. More than that, when working on the form code I had to constantly keep track of the types of things in my head, because there was no way to have the computer do it for me (we did try Hungarian notation for a bit but that was a disaster). Is it the end of the world? No. Does it slow development? Absolutely.

Re: Go is moving to GitHub

#140
post #60

Earlier quoted context omitted.

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.

We (the Go team) regularly have conversations about all kinds of programming paradigms, because we're into that kind of stuff. Some of us really like functional programming languages. But Go is not that kind of language, so those primitives do not belong there. Go is not everything to everyone, and it would be a mistake to try to make it that way. That doesn't mean that we don't see those things as generally valuable…

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.
Post reply on HN