Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go is moving to GitHub

groups.google.com

Post reply on HN
Print view View original

121–130 of 244 posts

Re: Go is moving to GitHub

#121

Post by chrisconroy »

shurcooL wrote: post #49
bbx wrote: 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.…

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

Re: Go is moving to GitHub

#122

Post by frobware »

enneff wrote: post #19
tkrajcar wrote: post #11

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…

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.

Re: Go is moving to GitHub

#123

Post by Laremere »

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.

Re: Go is moving to GitHub

#124

Post by user567 »

enneff wrote: post #105
user567 wrote: post #104

Earlier quoted context omitted.

You've written tomes on how wasting vertical space and multiplying syntactic noise is a good idea? Even if so: ideas are not measured by the volume of noise you write in support of them.

At the risk of prolonging this insufferable "conversation": my point is that it has been discussed to death, and you're being down voted because nobody is interested in discussing it with you, or even hearing you discuss it.

In that case, it's probably an extremely good sign that you've made a stupid decision in your language. Smart people are revolting and making noise. gofmt using tabs is another unbelievably stupid decision. I'm sure there was a good deal of talk around that one too.

Also, not just one comment. That entire thread shows the pigheadedness of the Go way.

Re: Go is moving to GitHub

#125

Post by nightcracker »

smt88 wrote: post #118
arh68 wrote: post #77

Earlier quoted context omitted.

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.

What are gits huge problems and what other technology solves those?

Not trying to put you on the spot, just curious.

Re: Go is moving to GitHub

#126

Post by rurounijones »

enneff wrote: post #62
nathany wrote: 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!"

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.

Re: Go is moving to GitHub

#127

Post by tinco »

bigtunacan wrote: post #92

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.

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?

Re: Go is moving to GitHub

#128

Post by sandGorgon »

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.

Re: Go is moving to GitHub

#129

Post by rurban »

frobware wrote: post #122
enneff wrote: 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.

With git and github you can have the best of both worlds. merge commits (seperate tree), linearized at the end (--no-ff) or rebased commits (pull --rebase).

1 and 3 have their usecases, 3 is esp. useful if the branch contains only 1-2 commits, and 1 is useful if the branch contains > 10. You can add test information into the merge commit.

I hope github will take more gerrit features into their tracker or allow tracker extensions, so that we can live with github alone. gerrit still is a UI and performance nightmare.

Re: Go is moving to GitHub

#130

Post by Matumio »

nightcracker wrote: post #125
smt88 wrote: post #118

Earlier quoted context omitted.

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.

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