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.
Go is moving to GitHub
131–140 of 244 posts
Re: Go is moving to GitHub
#132Earlier 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
#133Earlier 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.
Re: Go is moving to GitHub
#134Earlier 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…
Re: Go is moving to GitHub
#135Google 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.
Re: Go is moving to GitHub
#136It 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.
Re: Go is moving to GitHub
#137Earlier 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.
Re: Go is moving to GitHub
#138Earlier 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.
Re: Go is moving to GitHub
#139Earlier 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?
Re: Go is moving to GitHub
#140Earlier 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…