
Go is moving to GitHub - davecheney
https://groups.google.com/forum/#!topic/golang-dev/sckirqOWepg
======
DigitalSea
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 time.

Kudos to the Github team for well and truly making it as the premier code
hosting and collaboration tool for developers and lovers of open source. It
only goes up from here.

~~~
mholt
> I think this is Google quietly admitting that Google Code is all but dead.

Well, I doubt that Google Code engineers or project managers had much, if
anything, to do with the decision to move the Go project.

~~~
coldtea
That they didn't have a say in this matter though, speaks volumes...

~~~
skj
It would if the whole idea wasn't based on an assumption with no evidence.

~~~
coldtea
You mean we need evidence to know that moving Go to GitHub would be against
the interests of the Google Code people, and that they would protest such a
move?

Being cautious is one thing, being a sucker for being too cautious is another.

There are things like obvious conclusions.

------
bbx
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'm impressed.

~~~
jbergens
Am I the only one who thinks some more competition would be nice? I would like
to see more code move into BitBucket or similar. New version of Kiln will make
it possible to use Git and Mercurial against the same repository which sounds
like a great feature (not sure if there is a free plan on Kiln yet).

~~~
pestaa
You are not the only one. We finally have decentralized tools only to... put
all the eggs back into one basket!

~~~
coldpie
Sorta. The eggs you're placing into github's basket are different from the
eggs you've decentralized. I'd argue those eggs (merge requests, issue
tracking, discussions) have never really been successfully decentralized.

------
mholt
This is a huge compliment to GitHub, for Google to be moving one of its
premier open source projects off of Google Code and onto GitHub.

More importantly, though, this is a significant compliment to the Go
community, for Go to uproot itself and move to where the majority of its users
are.

~~~
fleaflicker
They moved many of their popular Java projects recently: guava, guice, closure
tools, gson.

------
yid
The writing's on the wall for Google Code. I don't think I've seen a new
feature in several years.

~~~
ch4s3
I'd love for them to just go read only, a TON of academic work lives on there,
but its awful to use.

~~~
kyrra
I much prefer Google code defect tracker to the GitHub one. But that's about
the only plus of Google code.

(Though, a small part of me wants mercurial to live on, but it doesn't seem
like that will happen)

~~~
ch4s3
That defect tracker is nice. I've never used mercurial so I can't comment on
that. Github keeps getting better, I'll bet if people asked for improvements
to defect tracking we might get them.

------
annnnd
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, there
really isn't much difference between the two (too bad GitHub only supports git
though).

~~~
nbouscal
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, but it certainly strikes me as
significantly less elegant than Git's. (I'd be happy to find out I'm wrong
about this - I know Git's model pretty intimately but am only moderately
familiar with Mercurial's.)

This problem seems to generalize quite a bit. Emphasis on surface-level
characteristics rather than core differences seems to be prevalent in
comparisons of databases, programming languages, web frameworks, etc. This
seems quite bad, but I have no idea how to fix it.

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

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

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

~~~
andrewchambers
git is still git - people don't even need a github account to have full
functionality.

~~~
icebraining
How many Github projects accept git format-patch submissions? There's
functionality beyond the basic DVCS commands.

~~~
dsymonds
In Go's case, we will be using Gerrit (elsewhere) for accepting submissions.
GitHub will _only_ be used as a source code mirror, wiki and issue tracker.

~~~
NateDad
Wait wait wait... no pull requests? There's no way you could just hook up PR's
to gerrit? Using github just as a mirror seems to defeat the entire purpose of
github, which is to encourage more community members to contribute.

------
TheMagicHorsey
Google Code has a really bad user interface. This migration makes sense. I
wish they stuck with Mercurial and moved to Bitbucket instead, but Github is
still better than Google Code.

~~~
lxj
Google Code needs web and UX designers STAT, or it will die.

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

~~~
arsenerei
Gerrit is an absolute treasure of a tool. I shudder everytime I make a pull
request in Github because Gerrit's contribution model is _so_ much better for
my workflow.

~~~
jpgvm
It has some hairy points though. I have never liked it's review per commit
model (yes, I know you can circumvent this by using merge commits).

I think the Github style works, assuming you have a sufficiently good CI
system that can also receive GitHub web hooks.

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

------
stephenitis
Props on the move, it shows that golang is flexible to make moves for what's
best for the community rather than stick it out in google code. I hope this
results in benefits to the iteration cycle.

------
xkarga00
I was hoping for this transition for a long time! Github is far more accessive
and user-friendly than the Google repositories. Great move.

------
virtue3
Does anyone know what code review system they are using with github?

~~~
tkrajcar
I'm curious what Gerrit gets them that Github doesn't have natively, too.

~~~
enneff
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 see how this works for some people,
but I find it gross for each contributor to the Go project to have their own
public fork. What a mess.

\- Comments on pull requests are sent as soon as they are created. Gerrit
allows you to make many comments on a change, as drafts, and then send them
all in one go, sending just a single email. This is much easier to manage for
a large project.

\- Gerrit has the notion of multiple 'patch sets' for a particular change, and
you can see diffs between patch sets, so it's much easier to progressively
review large changes.

And there are many other small issues with the GitHub pull request process
that make it untenable for the Go project.

~~~
nathany
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](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 pull request from there. Some open source projects give out the commit
bit almost immediately, but with GitHub there's still that initial fork and
pull request to prove oneself.

Interested to see how Gerrit addresses this. GitHub doesn't have any way to
disable pull requests. :-(

\- I've completely disabled email notifications for this reason. There still
can be a huge number of notifications in app or via third-party mobile apps.
Rietveld is a lot more sane, I only saw notifications for things I was
actively working on.

\- I usually end up reviewing just the new commits individually. But that
requires figuring out which ones I had already reviewed. Not so bad with only
a few branches, but I can see it getting out of hand.

I really hope people from GitHub are reading this thread as they are working
to improve their tools. :-)

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

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

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

~~~
NateDad
I have to agree that not using pull requests is missing out on the best
feature of github. It's the social, low-overhead way to contribute to a repo.

It seems like it must be possible to hook up a bot to github that watches for
pull requests and submits them to gerrit... the Juju team has a bot that does
that for our Reviewboard integration. It won't work for more complicated
workflows that github doesn't support, like dependent branches or whatever,
but it lowers the barrier of entry for initial contributors that just want to
submit a simple fix. And the more advanced users can just submit directly to
our Reviewboard instance if they want the more advanced features.

Also, the public fork on Github is actually a feature - it means others can
easily see what you're working on. You need off-site storage for your personal
work anyway, right? You're not going to keep it local on your laptop, so
you'll need a branch somewhere regardless.

~~~
duaneb
GitHub code review is terrible. I don't blame them for not using pull requests
in the least. If not being able to pull is enough to stop people from
contributing, how much is their contribution worth?

~~~
NateDad
Why even move to github then?

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

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

~~~
tinco
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?

~~~
bigtunacan
You can do pull requests through github, but Subversion is still preferred.
Things aren't integrated; so for example if you look at
[https://github.com/ruby/ruby](https://github.com/ruby/ruby) you will notice
Issues is not enabled; instead you have to go to a separate issue tracker over
at [https://bugs.ruby-lang.org/projects/ruby-trunk/issues](https://bugs.ruby-
lang.org/projects/ruby-trunk/issues).

I still contribute, but the barrier to entry is higher; people have to hunt
the ruby home page to find this information which is not ideal.

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

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

------
Spitfire777
Hi Go team,

if you want an alternative for Gerrit code review, you can also use
[http://review.ninja](http://review.ninja). It's also open source, so you are
welcome to contribute.

Cheers, Mitch

~~~
skj
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 deal... In any case, the scary scope list prevented me from
experimenting.

~~~
Spitfire777
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!

~~~
skj
Here's a screenshot of some side-by-side diff action:
[https://fr.atlassian.com/wac/software/fisheye/overview/scree...](https://fr.atlassian.com/wac/software/fisheye/overview/screenshot-
tour/featureItems/0/featureItems/0/imageBinary/fisheye-side-by-side-diff.png)

Basically, it let's you look at the old code, or look at the new code, or see
how they're different, all at the same time.

Inline diffs (github-style) require you to keep a context as you scan through
code, and it makes it harder to keep everything in your head.

------
mwsherman
I’m concerned that it won’t get any stars.

------
tsmarsh
I guess its official, misogyny is ok in our industry.

Have we forgotten about:
[http://lmgtfy.com/?q=github+misogyny](http://lmgtfy.com/?q=github+misogyny) ?

I'm not sure github even experienced a dip in traffic.

There are github alternatives, it took me 30 minutes to remove my github
subscription and migrate my repos to bitbucket.

~~~
Shizka
I will bite.

How does using Github even remotely contribute to accepting misogyny in our
industry?

~~~
ta1976ta
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](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 - the white, straight, male group. It makes
tech culture worse.

If I'm aware that you host on Github, I will make sure to consider what your
competitors are doing before I use your service.

~~~
Shizka
I can see how you could make it a valid argument like that. Thanks for
elaborating.

Do you think that not using services from companies with a monoculture is the
most effective way of furthering the cause? I'm all for more diversity in the
technology and startup sector, but I do believe that the cause should, and
eventually will, be solved by dialogue and focus on the issue - not by
silently boycutting the companies. Or am I missing some part of the picture?

~~~
ta1976ta
I can't say if this cause is better solved some other way, but I believe that
avoiding Github (not exactly boycotting it) and other big monocultures is the
right action for me to take. When I use a service, I give it a piece of my
economic power. I don't want to give that to Github.

I do believe a capitalist-based ecosystem can only be healthy with an
appropriate level of competition and alternatives for consumers. Github's
progress in the market is worrying in the sense that it seems to be driving
towards a monopoly.

Github can never be everything to everyone - if there is no meaningful
competition, it's guaranteed that some people will be excluded.

