Code.Google.com now supports git | Hacker News Reader

Code.Google.com now supports git

code.google.com

445 pointspixelbeat77 comments

Project administrators can now switch their source repo to git (or mercurial or subversion). From the page:

"This chooses the type of version control repository used to store the project source code and wiki. Modifying this setting will not delete existing Git, Mercurial, and Subversion data, but it will change the way the site displays your project's contents."

Open articleView on HN

I'd say a better link is to the issue we marked 'fixed' :

http://code.google.com/p/support/issues/detail?id=2454

Or to the project creation page:

http://code.google.com/hosting/createProject

We hope you like it.

Open source your projects using Google Project Hosting

Google Project Hosting is a fast, reliable, and easy open source hosting service. Google Project Hosting gives you:

    + Instant project creation on any topic
    + Subversion and Mercurial code hosting with 2
      gigabytes of storage space
    + Download hosting support with 2 gigabytes of storage
      space
    + Integrated source code browsing and code review tools
      to make it easy to view code, review contributions,
      and maintain a high quality code base
    + An issue tracker and project wiki that are simple,
      yet flexible and powerful, and can adapt to any
      development process
    + Starring and update streams that make it easy to keep
      track of projects and developers that you care about
*

How about linking Google code to Google+. Where projects have their own 'Project+' personality and what not. You could even have a 'downloads' like 'Photos' for all the people who don't seem to like GitHub (don't know why but ok).
I have tons of more suggestions... of course they will need to be validated :-P

Bring em on! Most of the work on the site is bringing some needed aspects to the fore, but the success of the + launch has spawned some really interesting ideas on how we can help users of the site share aspects of their projects to +.

Interesting. By forcing a new product name to be a recognized symbol, you remove all translation issues for the product name itself.
English? Google +. Italian? Google +.
Sneaky/clever.

The name "Google" itself doesn't get translated, either.

Done! http://code.google.com/p/support/issues/detail?id=5569

I got an email alert on that issue and all it said was resolution changed to fixed, with no comment. I thought it could be a mistake so I went to code.google.com looking for some kind of announcement and found nothing, then finally found the create project page and saw the drop-down with git in it!
Thanks for all the hard work you guys have put into it. I think many people don't realise how much work goes into something when you deploy it on a Google scale.

The team has done some good work and have indeed been working hard. They do appreciate the recognition for sure.
We talked about how we should break the news that we supported git. Marking the bug fixed was a good approach to it as then we knew those that cared enough to click on the little star on the issue would know, and that would be a pretty good start.
A few people noticed in the 1/2 hour or so between the launch and the issue change, so that was funny to watch. We'll do a formal post later. Right now we're mostly watching and seeing what happens so we can make sure the site is in good shape.
So....try it out and let us know how you like it.

Any chance of fixing this bug?
http://code.google.com/p/support/issues/detail?id=840#c6
It's totally bizzare to get other people's Google Code traffic data in your Google Analytics.

So does the backend use Java Git, or some specialized version of C git?

Why only those two alternatives?

I imagine they may just be the only two that the poster knows about. It's not like it's a radio button poll, though. It's enough to spawn a discussion. Someone that knows can respond in free-form.

They are most likely, but I suppose anything is possible.

Neither: Dulwich.

http://code.google.com/u/dborowitz@google.com/ - wow, neat to see dulwich in use for such a big project.

That's great, but I'm still slowly moving my projects over to Github.
1. I get much more engagement from random developers on Github. On Github, random people will fork and add features, do code reviews and leave comments. All of these things are technically possible on Google Code but nobody does it—probably due to the usability but possibly also a cultural problem. Github has a strong culture of collaboration because they strongly emphasize it in the user's experience.
2. Managing forks and pull requests is easier on Github. I want my life as a maintainer to be as easy as possible.
3. Notifications: For a long time, Google Code notifications simply didn't work for me, at all. I'd randomly stumble on one of my older projects and noticed 5 new issues opened that I didn't know about, I felt like I betrayed my users for 6+ months. Now they seem like they do, but some trust has been lost.
4. Multiple choices of documentation markup on Github is appealing.
5. The code browsing feature on Google Code feels like its own application. When you open a Github project, first thing you see is the code. On Google Code it takes 2 more clicks (that's 1 more click than Bitbucket). Think about what's the most important thing here—the code, and Github got it right.
As far as version control goes, I'm happy with either Git or Mercurial.

(Speaking purely for myself here.) I agree the code is important, but I think a cohesive project is more important. Github presents itself as a giant pastebin for code, with "projects" bolted on. Google Code presents projects first, and puts the code at an even level with every other part: bugtracker, downloads, wiki.
(That said, I agree pull requests would be cool.)

While I agree with you on the facts of projects vs code, I actually LOVE that the PROJECT isn't on github. It makes the wily nilly use/patches from 3rd parties so much easier. It makes Google Code feel a little too sourceforgey.

That's the problem with Google Code, in my opinion. It tries to be both a landing page and a project manager for my software when I'd rather take care of the former myself. It ends up sucking at both, unfortunately.

check your .html files in to your repo and serve them from projectname.googlecode.com. You can even set your project homepage to redirect there automatically if you are clever.

Same can be done on github. I can even do a cname redirect on a bare domain.
When a user thus opts for this functionality what then is the differential factor in comparing it to GitHub?

very little, clearly.
both can host project homepages in a variety of ways. GC gives you a navigable and clean and usable project landing page by default, while github makes you work a bit harder. neither service prevents you from doing what you want, but if you care about your non-developer users, you'll find better conversions using google code. fact.
to the OPs point, there is no reason why you can't make your GC project page have more content for developers. it is a wiki. everybody loves wikis.
the OP of this thread is clearly trolling, though.

I think I'm going to make a module to help people with GitHub repos create a friendlier layout for non-developers.

- Basically the front page of any google project is like the readme in github or bitbucket. Some repos use github pages for a full site. This makes it like a google code site and better as you can actually host content.
-Issues? Github has that. -Wiki? Same.
I don't see anything feature wise that Google brings to the table that GitHub or Bitbucket doesn't out of the box or manually with even greater control.
I really want to understand what the issues are, help me understand.

my take on it is that gc is better at running long-lived projects or projects with non-developer users. github is great, but its emphasis is strictly on coding and dvcs.
i've run svn gc projects, and projects on github, and found the gc stack to be generally more robust, cohesive, flexible, and methodically designed. ex: compare the rich functionality of the gc issue tracker to github and you'll find them incomparable. or, create a project and browse the "advanced" tab of your project and you'll probably find you have more control than it feels like, with little effort.
regarding "can actually host content" - prolly a red herring because both let you host content. they just present a different ui for it.

I think what he means is that you can actually design a site for your project and host it on Github. For example:
http://mxcl.github.com/homebrew/
Are there any non-google sites that do this on google code? As far as I can tell, all of them look like this:
http://code.google.com/p/waf/
Which is fine, but I'd hardly say that a new user would find that less daunting than the Homebrew page. There's a lot going on, and it's trying to cater to both people who want to use waf and people who want to work on waf.

yes, you can actually design a site for your project and host it on google code. directing your users to the gc-provided default is your choice.
the contents of your repositories are hosted available at projectname.googlecode.com, and you can serve HTML just like you can code. example: http://json-template.googlecode.com/svn/trunk/doc/On-Design-...
the urls are not as nice but github's aren't great either.

Thanks, I didn't know that. They should publicize that feature so that more projects use it.
I still find Github's detached gh-pages branches to be really clever and convenient.

Agreed, and yet implementing the features that make Github (& Bitbucket) what it is doesn't sound terribly difficult, and most importantly won't ruin the other "project-y" features of Google code.
Personally my projects are still on Google code, but Github is becoming more and more tempting.

Why doesn't anyone ever think about the users? You know, the ones that just want to grab some binaries and do stuff?
In the "old days", projects would have a webpage with some instructions, screenshots and downloadable binaries. The effort required to do this would pay off in terms of polish and would attract more users.
Today, people find out about this supposedly nice piece of software, and proceed to find only a source file listing, no documentation (not even a half-decent README), no screenshots and, worst of all, the need to build from source. I'm a technical person with a fair amount of curiosity for these things, and I find myself frequently bummed out and give up when I see a link to github.
Even when these "artifacts" exist, just the look of the site is enough to put regular users off.
Sharing code is not only about dumping a source tree online. It's about polishing all that surrounds it and makes it a "product". Without users a source tree has no value.
Frankly, the current situation is making the open-source community more and more closed in on itself. The first step for irrelevance.

I've never seen this. Any concrete examples?

Any project on github. Put yourself in the shoes of a user that doesn't want to donwnload source. He lands on a github project page and just gives up.
For a regular user (where "regular" depends on the type of software and the technical skill it requires), this is going way back to the days of source sharing on Usenet, way before the open-source term was mainstream (or even coined).

Why would someone go to GitHub if they don't want to download source code?
Please, an example.

I agree, and to go further, even _if_ a non-developer did on github (maybe higher in the search rankings), for many popular projects you can generally find the consumer facing url via the "homepage" link.
Example: https://github.com/rack/rack homepage url points to http://rack.rubyforge.org/
https://github.com/tenderlove/nokogiri => http://nokogiri.org/
https://github.com/mxcl/homebrew => http://mxcl.github.com/homebrew/
https://github.com/joyent/node => http://nodejs.org/
etc, etc.
It also seems fairly common to put the 'consumer' url near the top or bottom of the README.

In Github's case, most of the projects there are libraries and the users are developers. The people who like Github probably expect the first thing they see when they show up to a project to be the code. And I'd wager that for many developers, checking out the repo is quicker and more convenient than downloading a tarball.
Github's UI admittedly doesn't make for a great experience for someone browsing around looking for software to download. A project that is trying to appeal to regular users should set up a wiki page, or even better, use Github Pages to build a site.
Though, I really hate it when I follow a link to a Rails app on Github that left the default "Welcome to Rails" readme.

When looking out for libraries I need to have answers to the following questions:
1. Is the library stable/complete? 2. Is the API stable? 3. If not, how frequently/how much does it change?
With a decent project page, I can have these questions answered either directly or by looking at the available downloads history (even if they are source-only downloads) and version numbers. With github projects I frequently can't answer any of those questions.
Libraries are products, just like any other piece of software.
I'm not saying that github isn't good for developer collaboration. I'm saying it's no good for developer-user relations. It has the necessary features, but it doesn't encourage its use by the very nature of its interface.

1. Look at the README. 2&3. Semver.
Number of followers/watchers is usually a good indication of how well-liked a project is. And as with any other open-source software, without sniffing in the code a little bit you never know what you're getting, regardless of how good the docs are or how sleek the project hosting pages are.
I like how most bigger projects are doing it nowadays: a separate page/mini-website, often using GitHub pages, that is user-centric and usually has a direct download link, and then GitHub for fellow developers.

GitHub and Bitbucket is for code, and for people to interact with other coders.
You really don't go to GitHub and Bitbucket to download your favorite binary. That is what sourceforge, Top100 xyz, and Cnet is for.
The projects that are popular have people willing to help (read: contribute) to the project in classic open source engagement.
On top of that, GitHub & BitBucket enable the single/small group maintainer to write a readme that gets displayed.
I use both.
If your fav project doesn't have Mom+Pop friendly page with <download here> by all means please fork + contribute.
See:
http://documentcloud.github.com/backbone/
http://mbostock.github.com/d3/
http://github.com/jquery/jquery

Whenever I go to download an open source project, I end up on a web site built for it which has exactly what you mention. GitHub doesn't have those, but GitHub isn't intended to be the first page the end user finds either. GitHub is for developers, and any project that wants to be accessible to non-developers should set up a separate page as well. Nothing wrong with that from what I can see.

Well, you can easily set up a friendly page at username.github.com/project with gh-pages, and link users to there.

Minor quibble, but I share your concern. It is more of a developer choice rather than a github limitation. github supports pod format, README, and I have no idea what else, displayed on the front page of a project. You can also supply a link to a project page. But what do I expect? Same as you -- main feature description, screenshots (please), and additional links to documentation and examples.

I think the strength of GitHub is lying in it's focus on code. And that's the point of a code hosting website, isn't it? You visit a GitHub repository... what's the first thing you see? Instead of a blank page with some numbers and a project summary you're directly looking at the core of every project: its code. The presentation of the readme file is just one more thing which speaks for GitHub. Your project summary is integrated into the actual process of development because it's a part of it.
Plus, you really get this feeling of activity while browsing projects and code on GitHub. Google Code and SourceForge seem so abandoned in comparison.

Are there really any reasons to use Google Code when GitHub is kicking so much ass?

Its a distributed system. Use them both if you want. Each have their strengths.

Its a distributed system. Use them both if you want. Each have their strengths.
This is what I do. I like the way Google Code is oriented around giving you more of a "project" view, so I have a Google Code page for my projects, but I replaced the "Source" link with the link to the corresponding Github repo. I treat the Github repo as the primary repo for development, but I do use git-svn to push the code to Google Code SVN as well.. I figure it makes a convenient "read only" mirror for anybody who just wants to check the code out, play with it, whatever, but who isn't really interested in contributing... or for people who don't know how to use Git yet.

so is bitbucket and bitbucket has unlimited space if you are under 5 users per project

Bitbucket? No, thanks. It doesn't have the awesomeness of GitHub. GitHub uses JavaScript for everything. You have keyboard shortcuts, AJAX repository browsing, awesome issues system...

BitBucket also lets you have unlimited Private repositories, which can be important (e.g. versioning personal files).

Lack of git support is one of the major things that has prevented me from using google code. I'm happy to hear it's resolved. :)

While I agree with the sentiment in this thread that developers aren't going to be flocking over from GitHub anytime soon, at the very least this should help keep GitHub motivated (not that they've given us any reason for concern thus far). Competition is a good thing.

Google Code's UI needs a lot of work. I just created a test project to try our git functionality. I closed my browser and went to a meeting. After an hour or so I come back, open my browser, and type in code.google.com. I get a nice page but no links to "my projects" or the like. After searching through links on the page I finally had to give up and had to type in the project URL (http://code.google.com/p/myproject) from memory.

ck the "My Favorites" link in upper right

After further investigation I found out the "My Favorites" link doesn't show projects that were marked for deletion but not yet deleted.

> Google Code's UI needs a lot of work.
I disagree. I think it's a nice, simple, tidy interface in contrast to github's flashy one.

Waiting to get invited to a Google Code drinkup.

If they allowed private repos under your google data quota it would be a github killer because UI doesn't matter then and github is overpriced for that unless you throw all your code in one repo.

Does anyone know if it supports authentication using SSH public key instead of another password?

I like gthub.

Hoorah! This is great news.

I for one really like google code.

That's awesome.

finally.

I see it also still supports horrible UI. Pass.

Unhelpfully snarky way to put that. Why not say "Getting Git is great. I hope that the UI is improved soon too."?

Or even better, explain what about the UI could be improved. I've been using Google Code for several years, and I love the UI.

For starters:
What is the #1 reason to visit a project page? To download the source. Does the #2 reason come even close? No. So why in the world is the repo URL not on the front page, and easy for me to copy/paste into a terminal? Why? Github even has a button that will copy it to the clipboard for you!

Meh. The term 'Project' embodies much much more than just 'code'. A Project is made of its many components: team, community, bug trackers, documentation, resources, news feed and code (I've certainly omitted several other things).
Only after looking at these elements can you get a picture of the project which will tell you a lot about it. How is the support? Do developers even care? Are they serious at issues handling? Etc.
OSS suffers a lot from people who think they can just paste the code, change the implementation when they feel like it, etc.

"How is the support? Do developers even care? Are they serious at issues handling? Etc."
This can't be stressed enough. A prospective user first-and-foremost wants to have an answer to the question "Is this piece of software worthy of my time?". If it fails to answer this question quickly, it will lose the user.
We are used to seeing this kind of ignorance from corporations: "Let's dump this piece of code online. A community will form and users will come by the millions." How many times has this worked?
Right now there are loads of interesting projects on github. Projects that will never be sucessful because they failed to do the extra effort required to "market" them.

Thanks, that brings up another Google Code ui failure.
The front page of a Google Project gives you no indication if the project is being maintained.
When I go to a project on Github this is my flow:
1) When was the last check in? 18 months ago? Pass. Recent? Yes, please.
2) Usage examples? No? Maybe if I really need you. Yes? I'll at least give you shot.
3) Copy git url to the clipboard and then clone it.
Google Code doesn't do a good job of any of these!

1) At the top of the sidebar, there's an "Activity" label with a little cellphone-reception-style indicator icon. Clicking on it shows you a list of checkins, bug updates, and wiki modifications.
2) It's up to the project to show usage examples. Given that Google Code projects have a wiki page as the first thing you see, the examples can be in an even more prominent place than on GitHub.
3) Yeah, there's an extra click and some manual text selection here.
I don't know. I think it strikes a decent balance between letting developers get to the information they want and not scaring off non-technical users.

I disagree with your #1 reason. When I visit a project page, I most often only want to know what the hell the project is about.

Well, I'm going to say that you already have a gist of what the project is about otherwise why would you be on that repo Unless you were literally randomly clicking.
GitHub allows messaging, why not ping the author? Or create an issue "Needs Documentation? Or even contributing to docs?

You seem to be under the impression that the only reason people consume open source projects is because they want the source code. For many use cases, they are simply consumers of applications, not developers. Google Code tries to satisfy both user groups (this is why all the project homepages are in a consistent format, downloads are easily accessible, developers don't have to learn markup to host docs, etc).
While Google Code has some work to do on DVCS features, I still find it far more generally usable and thoughtfully designed than GitHub.

Disagree strongly.
Every time I get passed a github URL, it plonks me in a daunting page full of source code. If you scroll down a page or 2 sometimes you can see a text README file that tells you WTF the project is about.
On Google code, you get a nice UI, telling you about the project, bug tracker, discussions, binaries, AND IF YOU WANT IT the source code.
I think github is built for developers, whereas google code is built for developers and users.

Almost every worthwhile repo on Github has a README. A lot of them even use markdown. In terms of the source code, Github is for Git users--people that care about the code and commit history. Google Code isn't tied to a single VCS like Github, but it should still be developer-centric. After all, it's Google Code, not some app store.

Google Code and Git are actually perfect for each other -- both have horrible UIs.

Reply on news.ycombinator.com