opensource.google.com

Menu
Showing posts with label Git. Show all posts
Showing posts with label Git. Show all posts

Introducing Git protocol version 2

Friday, May 18, 2018

Git Logo by Jason Long, CC BY 3.0.
Today we announce Git protocol version 2, a major update of Git's wire protocol (how clones, fetches and pushes are communicated between clients and servers). This update removes one of the most inefficient parts of the Git protocol and fixes an extensibility bottleneck, unblocking the path to more wire protocol improvements in the future.

The protocol version 2 spec can be found here. The main improvements are:
The main motivation for the new protocol was to enable server side filtering of references (branches and tags). Prior to protocol v2, servers responded to all fetch commands with an initial reference advertisement, listing all references in the repository. This complete listing is sent even when a client only cares about updating a single branch, e.g.: `git fetch origin master`. For repositories that contain 100s of thousands of references (the Chromium repository has over 500k branches and tags) the server could end up sending 10s of megabytes of data that get ignored. This typically dominates both time and bandwidth during a fetch, especially when you are updating a branch that's only a few commits behind the remote, or even when you are only checking if you are up-to-date, resulting in a no-op fetch.

We recently rolled out support for protocol version 2 at Google and have seen a performance improvement of 3x for no-op fetches of a single branch on repositories containing 500k references. Protocol v2 has also enabled a reduction of 8x of the overhead bytes (non-packfile) sent from googlesource.com servers. A majority of this improvement is due to filtering references advertised by the server to the refs the client has expressed interest in.

Getting over the hurdles

The Git project has tried on a number of occasions over the years to either limit the initial ref advertisement or move to a new protocol altogether but continued to run into two problems: (1) the initial request is rigid and does not include a field that could be used to request that new servers modify their response without breaking compatibility with existing servers and (2) error handling is not well enough defined to allow safely using a new protocol that existing servers do not understand with a quick fallback to the old protocol. To migrate to a new protocol version, we needed to find a side channel which existing servers would ignore but could be used to safely communicate with newer servers.

There are three main transports that are used to speak Git’s wire-protocol (git://, ssh://, and https://), and the side channel that we use to request v2 needs to communicate in such a way that an older server would ignore any additional data sent and not crash. The http transport was the easiest as we can simply include an additional http header in the request (“Git-Protocol: version=2”). The ssh transport is a bit more difficult as it requires sending an environment variable (“GIT_PROTOCOL=version=2”) to be set on the remote end. This is more challenging because it requires server administrators to configure sshd to accept the new environment variable on their server. The most difficult transport is the anonymous Git transport (git://).

Initial requests made to a server using the anonymous Git transport are made in the form of a single packet-line which includes the requested service (git-upload-pack for fetches and git-receive-pack for pushes), and the repository followed by a NUL byte. Later virtualization support was added and a hostname parameter could be tacked on and  terminated by a NUL byte: `0033git-upload-pack /project.git\0host=myserver.com\0`. Ideally we’d be able to add a new parameter to be used to request v2 by adding it in the same manner as the hostname was added: `003dgit-upload-pack /project.git\0host=myserver.com\0version=2\0`. Unfortunately due to a bug introduced in 2006 we aren't able to place any extra arguments (separated by NULs) other than the host because otherwise the parsing of those arguments would enter an infinite loop. When this bug was fixed in 2009, a check was put in place to disallow extra arguments so that new clients wouldn't trigger this bug in older servers.

Fortunately, that check doesn't notice if we send additional request arguments hidden behind a second NUL byte, which was pointed out back in 2009.  This allows requests structured like: `003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0`. By placing version information behind a second NUL byte we can skirt around both the infinite loop bug and the explicit disallowal of extra arguments besides hostname. Only newer servers will know to look for additional information hidden behind two NUL bytes and older servers won’t croak.

Now, in every case, a client can issue a request to use v2, using a transport-specific side channel, and v2 servers can respond using the new protocol while older servers will ignore the side channel and just respond with a ref advertisement.

Try it for yourself

To try out protocol version 2 for yourself you'll need an up to date version of Git (support for v2 was recently merged to Git's master branch and is expected to be part of Git 2.18) and a v2 enabled server (repositories on googlesource.com and Cloud Source Repositories are v2 enabled). If you enable tracing and run a `fetch` command requesting a single branch, you can see the server sends a much smaller set of references when using protocol version 2:
git clone https://chromium.googlesource.com/chromium/src.git
cd src
export GIT_TRACE_PACKET=1

# Using protocol version 2
git -c protocol.version=2 fetch --no-tags origin master

# Using the original wire protocol
git -c protocol.version=0 fetch --no-tags origin master

By Brandon Williams, Git-core team

Updated December 5, 2018: Previously the example above used the more rarely used "git ls-remote" command. A recent change to improve the correctness of that command's output causes it to request more references. The updated example above demonstrates the improvement that protocol v2 brings using the "git fetch" command.

Hesokuri - a personal backup solution for your source code

Thursday, September 12, 2013

If you are a developer, source code is some of the most important data you have. It needs to be backed up regularly, it must be readily accessible from all of your machines, and it may even be confidential. Most of the code is probably already stored under version control.

With this in mind I developed Hesokuri, a background process that keeps Git repositories on multiple machines in sync. Changes are pushed aggressively to peers as they are committed. When a peer is offline, Hesokuri will retry a push regularly until the peer responds. In some cases, a peer will merge pushed commits into the current branch so they are immediately visible in any open text editor. This means that if Hesokuri is running on two or more networked machines, the Git repositories on them are duplicated, backed up, and widely accessible.

Once you have set up Hesokuri and written a simple configuration file, you can just use Git as you always have. Hesokuri also has a web interface so you can check what revisions of each repository have been pushed to each peer.

We are still working on the user interface and the list of features that we want to include, so thanks to the community in advance for your bug reports, pull requests, and other contributions!

For the source code and how to get started, check out the Hesokuri project page. You can also get help using Hesokuri and discuss improvements in the Google discussion group.

By Matthew DeVore, Google+ Team


Gerrit Hackathon #3, May 7-11, 2012

Wednesday, May 30, 2012


A great thanks goes out to Google for hosting the 3rd Gerrit Code Review Hackathon earlier this month at their Mountain View campus, it was well attended and very productive.

After quickly deciding to focus on adding a plugin framework to Gerrit during the hackathon, we discussed a few areas which could really benefit from plugins (authentication, hook, events, UI) and we identified new SSH commands as a possible quick prototype objective. After discovering some minor pitfalls of intense collaboration using Gerrit, we realized that we could make good use of the new Gerrit builtin rebase button. The rebase button did indeed come in handy for many of us to avoid overwriting each other’s changes with rebases, but we quickly noticed that simply having the owner and submitters allowed to rebase would not be adequate. This led to the proposal to upload a new rebase permission, which has been backported to be in the 2.4 release since that is the first release with the new rebase feature.

There were other minor Gerrit UI quirks discussed and fixes proposed for many of these during the following days:
user links now link to the owner:user search instead of to the user’s dashboard, most of us found  that this is what we really want most of the time.
Fixing the lack of reviewer visibility in the case of draft reviews
set-account ssh command was also merged.


Now back to plugins; we completed our first prototype for SSH commands early Tuesday and we were on our way to a plugin framework.  We decided to break plugin concepts into 2 main types: plugins with full access to Gerrit’s internals (and bound to a specific Gerrit version), and extensions which would only be bound to light stable interfaces. Plugins and extensions both got their own classloaders, but extensions were isolated from Gerrit classes. Helloworld sample plugins and repositories were created on gerrit.googlesource.com for several of these allowing users to host plugins alongside Gerrit as distinct projects.

Shawn Pearce created two jar files to compile plugins and extensions against, the plugin jar is one massive jar with Gerrit and all its dependencies in it. This large jar file should make it possible for plugin developers to create plugins quickly without having to download the many dependencies independently using maven. The extensions jar file consists mainly of the new fairly sparse top level gerrit-extensions-api package.

Other plugin accomplishments:
plugins got their own Guice injectors
HttpServlet plugin support in Gerrit
pegdown can be used by plugin developers to create lightweight documentation for their plugins
plugin command to be able to operate on and view plugins in a live Gerrit instance

With an initial plugin infrastructure in place, initial rework of the Gerrit core started by expressing part of it in terms of plugin: refactoring the replication as plug-in and introducing the ability to create aliases in order to use plugins commands as surrogates of existing commands. We added the ability to capture JSON/RPC and SSH actions to generate audit-trails and, later in the week, the ability to add extra custom commit validation through plugins.

Additional plugins have been created to provide long awaited functionalities in Gerrit, such as the delete project command and an online server viewer accessible through a web link. As the number of plugins is expected to grow quickly it was proposed that we define a simple but published process to allow people to search through existing plugins and host in Gerrit contributed plugins and their descriptive wikis.

The final day we focused on how topic branches might be approached in Gerrit. We decided we did not want to add support for change labels to the database since we are attempting to migrate away from the db. To put this data into git notes, it is necessary to have an indexing system and we concluded it would need to be done (or attempted) with Lucene. This could then pave the path for greater use of Lucene in Gerrit.

Scalability was naturally on many of our minds. Git maintainer Junio C Hamano joined our discussions of the many hacks being implemented to deal with the git protocol's ref advertisement performance impacts.  Android Gerrit users seem to push many of the original git use case assumptions beyond their original intents, especially when it comes to ref counts.  We were delighted to get Junio's approval to propose non backwards compatible changes to the git protocol to make our use cases more efficient.

We also spent some time outlining an incremental approach to making open source Gerrit clusterable (the version running for android-review and gerrit-review is already clustered but uses much of Google's proprietary technologies such as GFS and BigTable). Several incremental steps were outlined on how to move Gerrit in that direction. The first step which is needed is to support a very simple master/master installation of Gerrit where both (or all if more than 2) masters share a common filesystem backend (likely a high end NFS server) and a common db. Two issues were identified here which need to be resolved before this is possible: Cache coherency and Submit conflict resolution.

So while this is by no means a full run down of the week, it should give you some insights into the progress which we made during this week and also into some of the plans for future Gerrit directions. With the beginnings of a solid plugin infrastructure now in place, we hope that the Gerrit community will pick up the task of providing shared plugins for common tasks and host these new plugins alongside the gerrit project at the gerrit-review site.

Some fun stats (external contributions counted also):
New changes created during the 5 days of the Hackathon: 115
New patchsets uploaded during the 5 days of the Hackathon: 353
Changes touched during the 5 days of the Hackathon:143
Changes submitted during the 5 days of the Hackathon: 63
Changes submitted during the week after the Hackathon (many carryovers): 43

By Martin Fick, Qualcomm Innovation Center, Gerrit project submitter

This has been cross posted from the Repo and Gerrit Discussion List

Worldwide Mirrors of git.kernel.org

Tuesday, April 24, 2012


The Git version control system plays a big part in the development of the Linux kernel and its related utilities. Developers around the world need fast access to the repositories hosted by git.kernel.org.

Today Google is making available a public mirror of git.kernel.org at https://kernel.googlesource.com/. This mirror service is backed by the same high speed infrastructure that hosts the Android Open Source Project, which already serves more than 1 terabyte of data and 2.5 million requests each day.

kernel.googlesource.com is served out of multiple Google data centers, utilizing facilities in Asia, the United States and Europe to provide speedy access from almost anywhere in the world.

By Shawn Pearce, Open Source Programs Office

GitTogether 2011

Thursday, December 8, 2011

It has become an autumn tradition to host GitTogether, two days of unconference where Git developers, enthusiasts, and users gather at Google’s headquarters in Mountain View, California to share ideas on future directions of Git and to discuss the tools that support the larger ecosystem. This year was no exception. More than 55 people showed up for GitTogether 2011, and one thing that is notable is that at many of the attendees’ $DAY_JOB, the combination of Git on the desktop with Gerrit Code Review on the server side has become the standard set-up to run development work.

Photo by Brandon Casey

Google’s Dave Borowitz gave a talk about the recent addition of Git support to Google Code Project Hosting. Google also recently moved the Git server that hosts the Android open source community from kernel.org to an in-house Git server, which was the topic of Shawn Pearce’s talk. Junio C Hamano briefly described additional workflow elements being designed to help the kernel developers ensure the authenticity of the patch-flow after the recent break-in incident at kernel.org.

Since last year’s GitTogether, submodule support has been heavily enhanced. Jens Lehmann and Heiko Voigt, two Git developers who have been primarily working on the submodule support, gave an overview of where we are and what the future entails. The general direction is to make it easier to run various operations from the top-level superproject and have it go into submodules recursively when the project and the user choose to. There has been interest in using the native submodule support to update the implementation of “repo” wrapper used in Android and other projects. It seems that we are getting closer.

Support for large blobs that would not fit in the memory has been always lacking in Git. There recently has been a lot of work in the native support (e.g. storing them straight to the object store without having to read and hold the whole thing in core, checking out from the object store to the working tree without having to hold the whole thing in core, etc.). There are a few third-party tools and approaches with their own pros-and-cons, but it was generally agreed that adding a split-object encoding like Avery Pennarun’s “bup” tools uses would be the right way to help support object transfer between repositories to advance the native support of large objects in Git further.

The animated diff in Roberto Tyley’s Agit (git running on Android) demo was cool and received warm applause.

In addition to the technical discussions, we had a chance to get to know each other socially, enjoying lunches in the conference room (unlike the previous years, the group has grown too large to visit Google cafes without disturbing other Googlers) and dinners at some local restaurants. True to the tradition, there was a “patch of questionable value” to add different hash algorithm to Git in case SHA-1 hash collisions are found.

By Junio C Hamano, Open Source Programs

Announcing Git Support for Google Code Project Hosting

Monday, July 25, 2011

We’re pleased to announce today that in addition to supporting the Subversion and Mercurial version control systems, Google Code Project Hosting now supports Git. Git is a popular distributed version control system (DVCS) like Mercurial, and it is used by many popular projects including the Linux kernel and Android.



Now, when you create a project or visit your existing project’s Administration > Source tab, you have the option of choosing Git as your version control system. You’ll enjoy all the same great Google Project Hosting features, like project updates, advanced issue tracking, and an easy-to-use VCS-backed wiki—only now, you can do it with Git. You can also create an instant server-side clone of any existing Git repository by clicking the “Create a clone” button on the project’s checkout page.

For more information, including an introduction to Git and tips on converting existing Subversion and Mercurial repositories, see the new Git section of our support wiki.

Under the Hood
Since our original announcement of Mercurial support, Git has grown significantly more popular and user-friendly, and on the technical side, it has added an efficient “smart” HTTP protocol that fits with Google’s HTTP-based infrastructure. (Note that this feature is only available in version 1.6.6 and later.)

Like our Mercurial implementation, our Git implementation stores object data in a custom data store built on Bigtable, which provides us with efficient, scalable source code repositories with near-instantaneous replication to multiple datacenters around the world. To fit with our existing Python-based system, our Git server implementation is powered in part by Dulwich.

By Dave Borowitz, Google Git Engineer, with thanks to Augie Fackler, Lucas Bergman, Jacob Lee, and Shawn Pearce

Geek Time with Junio C Hamano

Friday, March 11, 2011



Junio C Hamano is a software engineer in the Google Open Source Programs Office who works on the open source project Git. Git is an increasingly popular distributed version control system that is used by many open source projects including Android, Chrome OS, and the Linux kernel. Jun is the maintainer and one of the primary authors of Git, with 4426 commits!

Jeremy Allison, co-creator of Samba and fellow Open Source Programs Office team member, recently sat down with Jun for some quality Geek Time. Samba uses Git, so there was plenty to talk about! Here are some highlights:

• Jun and Jeremy discuss how Jun began working on open source after the maintainer of GNU’s source control system RCS, Paul Eggert, began mentoring him. (0:56)

• Jun explains why he prefers working within the open source software development model. (2:50)

• Jeremy asks Jun how he became interested and involved with Git. (3:27)

• When Jun first started working on Git, he had to balance his time between working on an open source project with a day job. Jun reveals his secret for making this balance work, and also how he eventually integrated Git into his day job. (7:00)

• Jun and Jeremy discuss the growing popularity of Git in comparison to older version control systems, and Jun gives an overview of some of Git’s features that set it apart. (9:28)

• Jeremy shares his one criticism of Git, which is that it’s hard to use. Jun responds and offers some suggestions for those who are new to Git. (12:48)

• Jun reveals some longer-term goals for Git as well as some new developments for future releases. (17:44)

• Jeremy asks Jun how he ended up at Google and they talk about Git’s growing role within Google. (19:24)

• Jun gives advice to developers who are new to open source and want to get involved. (21:50)

By Ellen Ko, Open Source Team

GitTogether ‘10 at Google

Thursday, November 4, 2010

Last week around 30 Git developers and users gathered for GitTogether ‘10 at Google’s headquarters in Mountain View, CA for three days of hacking, sharing ideas, and making plans for the future of Git and its supporting tool ecosystem. This was the third time we’ve hosted a GitTogether, and we were really excited about the turnout this year. Based on attendees’ $DAY_JOB employers, Git is becoming much more popular in commercial development organizations, demonstrating yet-again how open source can be an effective alternative to traditional propriety development methods.


Here at Google we use Git on our big open source projects like Android and Chromium OS, but also for smaller projects like Gerrit Code Review or the Eclipse Git plugin, as well as our continuing contributions to the Linux Kernel. During my last 2 years at Google, I ( Shawn) have been working on Gerrit Code Review (a web based code review system for Git), as well as maintaining and improving JGit (a pure Java reimplementation of Git). Junio C Hamano, one of the earliest Git contributors and the current Git maintainer, also joined Google last May and continues to contribute to Git as part of his job duties.

The schedule for the three day conference was determined in “unconference” style, with topics for discussion originally suggested on the wiki and later developed in-person through sticky notes posted on a white board. Attendees also took advantage of the #gittogether IRC channel on freenode and an Etherpad server hosted by the OSUOSL, allowing individuals who couldn’t make it in-person to at least have a virtual presence.


The session scheduling process

In addition to the technical discussions, we had a chance to get to know each other socially, enjoying lunches in Google cafés and dinners at some local restaurants. Unfortunately the group failed to develop a “patch of questionable value,” where in prior years Sverre wore a hat, diff learned --pirate, bash completion earned a splash screen, and git auto-upgraded itself.

Photo by Thomas Rast

by Shawn Pearce, Open Source Team

Shawn Pearce on FLOSS Weekly

Monday, May 3, 2010




Recently, the Google Open Source Programs Office’s Shawn Pearce appeared on FLOSS Weekly for the show’s 118th episode. FLOSS Weekly was started by Leo Laporte and Open Source Programs Manager Chris DiBona in 2006, and in 2009 it was nominated for a Podcast Award in the Technology/Science category.

Shawn is the creator of JGit, a reimplementation git in Java, and he spoke to hosts Randal Schwartz and Randi Harper on version control systems, including Gerrit Code Review, JGit, EGit, and Git.

Distributed Version Control for Project Hosting Users

Friday, April 24, 2009

Love our Open Source project hosting service but wish it supported distributed version control? Pine no longer! You can find full details about Mercurial support for hosted projects on the Google Code Blog.

For those of you who are Git fans, you may want to check out these articles: Develop with Git on a Google Code Project and Exporting a Git Project to Google Code.

Happy hacking!



Ed. Note: Post update to correct link.

GitTogether '08

Tuesday, November 4, 2008



Last week Google played host to the first Git developer conference at its Mountain View headquarters. The 3-day conference was well attended, with almost 25 major contributors and users coming out to discuss the past and future of the Git distributed version control system.

Several major topics were presented, leading to some highly interesting new topics starting on the Git mailing list. A true Git library is now being planned, to provide native bindings into scripting languages such as Perl and Python. Major user interface improvements to git send-email and the overall user experience were also introduced and are well under way. A Google Tech Talk, Contributing With Git, was also given by Johannes Schindelin, and is now available to the public on YouTube.

More details about the sessions, including slides and notes, are available on the git wiki.

A big thanks to Google for supporting open source projects by offering meeting space for the conference attendees.

Git and Google Summer of Code

Friday, August 22, 2008



Many of you may remember our most recent episode of the Google Summer of Code™ podcast, Getting Giddy with Git. Now that we're heading into the program home stretch, we're back with an update on the success (and failures) of Summer of Code within the Git community.

This year Git was fortunate enough to get 6 very hard-working students, focusing on a number of different projects to make Git more portable and run even faster. Among our high-profile projects for 2008, Miklos Vajna's native C port of git-merge entered the main tree on July 8th, just one day after the mid-term evaluation period began. Miklos' work shipped as a key part of Git 1.6.0, released on August 17th. We were also excited to see Marek Zawirski's push implementation for EGit (the Eclipse plugin) enter the main EGit tree on June 28th, weeks before the program mid-term. Difficulties working with SWT caused Marek's GUI implementation to be delayed, but it finally showed up at the last minute as a 31 patch series. We are looking forward to seeing this in the fall EGit release.

To read even more about all of our great student projects, see the mailing list thread Jakub Narebski started during the 'pencils down' period. Jakub offers an excellent summary of every student project, and many of the students provide more detailed updates later in the thread.

Getting Giddy with Git

Friday, July 18, 2008

For Episode 18 of the Google Summer of Code™ podcast, we were fortunate enough to be joined by two mentors from the Git project, Shawn Pearce and Johannes Schindelin. Among other topics, we discussed the pleasures and perils of distributed version control systems, preparing an organization's application for Summer of Code, and some of the amazing work already completed by Git's 2008 GSoCers. You'll also get to learn the secret of Shawn's IRC handle and Johannes' commit messages, in addition to hearing about some great features in Git created by Summer of Coders and useful advice on engaging student developers in your community.

Many thanks to Johannes and Shawn for joining us!

You can download the podcast in mp3 or ogg formats. Alternatively, you can subscribe to it.

Is there a particular Summer of Code mentoring organization you'd like to see us interview? Comment away - we'd love to hear your thoughts!

Export a Git Project to Google Code

Tuesday, May 27, 2008



Git and Subversion can work together in many ways. Previously, we showed how Git users can work with a project primarily managed by Subversion. In this post, we describe one way to handle the converse: Google Code acts as a stable read-only Subversion mirror of a Git project. In this model, patches are first applied to the central Git repository and exported to Google Code later.

Instead of merely providing a link to your repository, why not widen your audience with just a handful of commands? Open up your Git-hosted project to all Subversion users, whose patches can be integrated via Git.

We presume some familiarity with Git, though blindly typing the commands below should produce acceptable results.

1. Create Subversion-aware Git clone

Naturally, your official source tree lives on some Git-capable server, which we denote by $GIT_REPO. After creating a new Google Code project, initialize an intermediary repository and fetch the Git tree:
$ git svn clone --username you https://your-project.googlecode.com/svn/trunk
$ cd trunk
$ git fetch $GIT_REPO
The Subversion repository must be nonempty. A new Google Code project contains one revision by default, but if you reset it, you should also create a first revision.

Create a temporary branch for the fetched repository, and tag its head:
$ git branch tmp $(cut -b-40 .git/FETCH_HEAD)
$ git tag -a -m "Last fetch" last tmp

2. Apply initial commit

Unfortunately, Git treats the initial commit specially, and in particular, cannot rebase it. Work around this as follows:

$ INIT_COMMIT=$(git log tmp --pretty=format:%H | tail -1)
$ git checkout $INIT_COMMIT .
$ git commit -C $INIT_COMMIT

3. Rebase and submit

Apply all the other commits to the temporary branch, and make it the new master branch:
$ git rebase master tmp
$ git branch -M tmp master
Lastly, commit the changes to Google Code:
$ git svn dcommit
To more faithfully represent deleted subdirectories and copies of unmodified files, run dcommit with the options --rmdir and --find-copies-harder. Be aware the latter option can be expensive.

4. Update Google Code

Later, export Git repository updates to Google Code as follows:

$ git fetch $GIT_REPO
$ git branch tmp $(cut -b-40 .git/FETCH_HEAD)
$ git tag -a -m "Last fetch" newlast tmp
$ git rebase --onto master last tmp
$ git branch -M tmp master
$ git svn dcommit
$ mv .git/refs/tags/newlast .git/refs/tags/last
For simplicity, we've exported directly to Google Code. It may be faster to first export to a local Subversion repository, and then mirror it to Google Code via svnsync.

Develop with Git on a Google Code Project

Tuesday, May 20, 2008



Do you often work offline? Wish you could make local commits that you can reorganize and upload later? Would you like to have your own copy of the entire history of the project which you can peruse at your leisure?

Do you want to serve code and its history to others? Have changes you want to share but it's too early for the public?

Working on several issues in parallel? Need to save some of those experimental changes after all? Need to create, merge, clone and otherwise manipulate branches cheaply and offline?

You can do all this, and more, with Git, a version control system rapidly growing in popularity. You can readily find Git tutorials, but since I'm writing this post, I'll shamelessly plug my own guide to Git!

Although Google Code natively speaks Subversion, you can easily use Git during development. Searching for "git svn" suggests this practice is widespread, and we too encourage you to experiment with it.

We focus on importing a complete Git repository from a Google Code project organized in the recommended fashion. The git-svn manpage thoroughly describes how to handle other cases such as nonstandard layouts, importing only a few revisions, sharing exported repositories, and so on.

1. Import

First we perform the equivalent of a svn checkout. In an empty subdirectory, run:
$ git svn clone --username your-name -s https://your-project.googlecode.com/svn
# older versions of git: replace "-s" with "-Ttrunk -bbranches -ttags"
Like a Subversion checkout, you now have a local copy of your project. Unlike a Subversion checkout, you also have a local copy of the entire history of the project. Try:
$ git log          # print summary of history
$ git diff HEAD^^ # diff against two revisions ago
$ gitk # graphical history browser
$ qgit # Qt-based history browser
These read from local disk, and work even when you're offline.

2. Develop

You now have a fully fledged version control system at your fingertips. You can checkpoint locally. You can create, merge, and destroy branches cheaply. You can checkout long-lost ancient code. You can stockpile and reorganize your commits.

Any Git tutorial teaches these abilities. We'll content ourselves with simple examples.

First, the basics. Edit code as usual, but if you add or remove files, type:
$ git add FILENAME...
or
$ git rm FILENAME...
There's no need to inform Subversion as git-svn will do so later. In fact, we only talk to Subversion via git-svn, and never run pure svn commands.

The only other git command you must know is:
$ git commit -a
which saves the current state of your project locally. You can see them with git log. Commit early and commit often!

Now for a couple of tricks. Let's say you've made several commits and suppose you want to undo the last one:
$ git reset --hard HEAD^
Or suppose you want to get a certain file from five commits ago:
$ git checkout HEAD~5 foo.c
We've barely scratched the surface. There are countless other features worth learning, particularly Git's extraordinary lightweight branches.

3. Update

Periodically, you should get online and fetch the latest changes from Google Code with:
$ git svn rebase   # think "svn update"

4. Export

Submit your commits to Google Code with:
$ git svn dcommit  # think "svn commit"
This converts each of your Git commits into Subversion commits and uploads them, provided your repository is up-to-date. To keep working, go back to step 2.

Stay Tuned!

We've seen it's easy to setup Git with a Google Code project. If distributed version control systems sound intimidating, the above is a great way to get your feet wet. You can always delete the directory and go back to Subversion.

But what if you keep your project in a Git repository, and you want to export it to Google Code? So you'd have a canonical read-only Subversion mirror of your project?

Exporting a Git project to Google Code requires only a handful of commands. We'll show you how in a future post.
.