on the story of browser names

One of the early graphical web browser that got really popular was Mosaic, developed at National Center for Supercomputing Applications (NCSA). Some folks from the team, along with SGI founder Jim Clark, decided that it's worth a venture and formed a company, originally called Mosaic Communication and then later renamed to Netscape Communication.

Netscape's flagship desktop product was a much more advanced web browser than Mosaic. Jamie Zawinski coined the name "Mozilla", as it was supposed to be Mosaic Killer (Mozilla = Mosaic + Godzilla). At the later stage, the final browser was widely known as Netscape Navigator. For browsing the web, obviously you need a navigator.

Parallel to that, another company called Spyglass licensed the technology from NCSA and produced a web browser, Spyglass Mosaic. It is fun to see the same theme here (probably even slightly coincidental), typical Hollywood movies always portray the naval ship's navigator using his spyglass for some sort of observations.

Then came along Microsoft. It licensed Spyglass Mosaic, called it Internet Explorer, and distributed with Windows. The browser war has just started. I mean of course, the name war. Why would you stop at navigating (and using spyglass) if you can continue exploring?

On the other side of the planet, KDE slowly emerged as the attractive supplement to the otherwise boring Unix desktop. Internet technologies became the centerpiece of the early version of KDE, thus its developers grew a set of applications from e-mail program, newsgroup reader, IRC client, and (surprise) a web browser. There was no free-software-friendly modern and capable web rendering engine back then, thus a bunch of brave young hackers initiated the adventure of (re)writing one, under the name KHTML (which was itself a replacement of the original attempt, khtmlw).

From this KDE camp, the ultimate web browser (which actually could serve other tasks as well, e.g. file manager and document viewer) was popular as Konqueror (indeed, those were the days where KDE stuff was named K-this or K-that). History showed how Age of Discovery was not about navigation and exploration only. After all, who would not want to repeat the glory of "I came, I saw, I conquered"?

When Apple decided that it must give the best browsing experience for Mac (and could not just rely on Microsoft for its Internet Explorer), they took KHTML, ported it to Mac, improved it, and later released it as an open-source project called WebKit. Apple's proprietary web browser, which is powered by WebKit (till today), was announced by Steve Jobs as Safari. Already conquered a land? Might as well enjoy it with a little bit of safari and collect exotic pictures. Shall we?

Just like in your favorite comic books, the world is however multiverse. Netscape lost the browser war, Mozilla became an open-source project and its Firefox browser (formerly Firebird, and formerly Phoenix) remains as the icon of freedom, independence, and community. Opera, originally a Telenor research project, was something that came all the way from Norway, has loyal followers and remains dominant in the embedded space. Google even joined the fun and launched WebKit-based Chrome (and Chromium). All these three are excellent web browsers, they just don't have the names which fit the story of navigation, exploration, and so on.

As the closing, here is a side twist. In its early WebKit days, how did Apple engineers name the code branch of its ported Konqueror's KHTML? Alexander.

yet another command-line JavaScript beautifier (based on V8)

While we're still on the topic of JavaScript, I took the afternoon break to create a command-line runner for jsbeautifier.org . In case you miss it, I did the similar thing using Qt Script module. This time however, the command-line tool uses and exploits Google V8 instead.

If you update your clone of js-beautify repository, check out the fresh v8 subdirectory. I also mirror the code in the usual X2 repository, under the javascript/jsbeautify8 subdirectory. Also, grok the included README.txt first.

Update: I added --overwrite option which (surprise!) will overwrite the original source file (and thus, use it with care). This is useful if you invoke the beautifier tool from your text editor. Nicolas also implemented various settings support so you can specify the indentation level, braces placement, etc.

This is probably the last thing the world needs now, but hey, it was a fun break.

on JavaScript engines

If you are using a modern browser, likely you already have the (arguably) most widely deployed scripting environment: JavaScript engine (or ECMAScript, if you insist). There are many things you can do with it (just look at tons of cool web apps out there). However, since it is contained in the browser, there are also things the embedded JavaScript engine can not do for you.

If you are using KDE, you also have two excellent JavaScript engines: KJS and Qt Script. You can embed either of them (i.e. KJSEmbed) and make your application scriptable. In a not-so-strange twist, they both relate (distantly) to each other via JavaScriptCore, WebKit's default JavaScript engine, because long time ago Apple forked KJS and used it as the base for JavaScriptCore, and Qt Script (for version 4.6 and 4.7) also uses JavaScriptCore as the back-end.

If you are interested in learning, using, and/or dissecting other open-source JavaScript engines, have a look at JavaScript Engines: How to Compile Them I wrote for our Sencha blog, which covers Mozilla's SpiderMonkey, WebKit's JavaScriptCore, and Google V8. The instructions should work on the supported platforms, including ARM, in case (just like me) you want to have and carry around every JavaScript engines in this planet on your Maemo-powered Nokia N900. That is fun.

As the closing, just remember, "Ask not what the JavaScript engine can do for you — ask what you can do for the JavaScript engine".

spring-to-summer: photo blog

Since I've not been blogging for a while, let me do a post on some pictures (plus the stories) instead.

On a weekend, Balboa Park is a very nice attraction. Rather than explaining it in details, I suggest to just drop the park a visit. Beside a lot of different types of museum, there is also this Japanese Friendship Garden. A small cafe there, the Tea Pavillion, is a very nice place to relax and enjoy the surrounding. They serve sencha and other types of tea. Hungry? Get a rice bowl:

If you are more a beach person instead, then there is a plenty of choices, for example Silver Strand Beach. It is rather small, but it is always a nice spot to enjoy the sunset.

When I was at Google IO, I took some pictures of the large overhang banners because I wanted to test the 8 megapixel camera of HTC EVO 4G that Google gave away (see more in the complete set):

Getting a fantastic gift for the Father's day? Thinking of something for the next Mother's Day? What about a beautiful pendant (get one from LuShae Jewelry) like what my other better half elegantly captured below?

google io 2010

In few hours, I am scheduled to fly to San Francisco, bracing for the impact of Google I/O 2010!

Quake and WebGL

While I'm there, let me just quickly blog about it. Using the developer version of Chromium on OpenSUSE, I just run it with the following arguments:

/usr/bin/chromium --enable-webgl --in-process-webgl

and then I have WebGL at my fingertip. You can test it with some O3D samples (the pool one is pretty cool).

In fact, just go ahead and play Quake II at http://playwebgl.com/games/quake-2-webgl/.

I got bad FPS because I own a cheap laptop (8 FPS is more than what I expect from a $330 box). Obviously you can get 25 FPS or more on a much better machine!

Chromium on OpenSUSE

Though Google Chrome for Linux is not yet officially announced, people have been working to make Chromium, the open-source version thereof, available for different popular distributions. I wrote before about CrossOver Chromium, but not only this is just a hack, it is also not up-to-date at all. The easiest way for OpenSUSE 11.1 users is to use the package from Contrib.

Though for veteran OpenSUSE fans, the steps to install Chromium are obvious, here I write down the idiot-proof version. Go to http://software.opensuse.org/search, type Chromium and click the Search button, wait for a moment, find the entry from openSUSE:Factory:Contrib/openSUSE_11.1, then well, click on the 1-Click Install button there. Follow the usual installation guides (mostly just agreeing and confirming some stuff), then in few minutes you will get:

Who says installing software in Linux is difficult? :)

it got cold and then dark so suddenly and rained

Cutting a long story short, check out my latest example of a less-than-150-lines code (pick your battle: C++ version or Python version) to show the weather status and day forecasts for almost all places in this blue planet, powered by Google, based on QtWebKit. As always, let's start with the screenshot (aka the proof):

I doubt there is a need for this to be a plasmoid, as it will just clutter Plasma with yet another weather applet. But hey, if people like it, I (or someone else, preferably) can make it.

Chrome Experiments, Flash-killer, Monster Evolution

These days I am juggling balls. Beside fixing QtWebKit-related bugs, writing more examples on using QtWebKit, I am helping the Kinetic guys with Graphics View optimizations, and working on new Graphics View feature I still can't elaborate (sorry for the teaser :-). On top of that, I already started to work on Qt Script, learning the intricacies of JavaScript along the way, stress-testing Kent's Qt Script binding generators, and surely also playing around with the brand-new Qt Script debugger in Qt 4.5. For the latter, even if you are not really into Qt Script, I highly recommend giving it a try, at least watch the screencast from Kent for a start.

Unless you stayed under the rock for the last few weeks, you already heard about Chrome Experiments. These are some extremely cool demos designed to run in a web browser. Of course, there are already tons of demos out there. Chrome Experiments are however different. It relies on a high-performance browser. The reason: the demo is JavaScript intensive and thus a blazing-fast JavaScript engine will make a different. Coupled with the use of HTML 5 Canvas, some of demos simply show many things which are not possible before. Flash will be still here to stay (due to its authoring tools, advanced features, libraries collections, and so on). But I won't be too surprised if this is going to be a Flash-killer technology. There is O3D but I reckon it tackles a different market segment.

My favorite Chrome Experiment is Monster Evolution, an fantastic demo written by Dean McNamee. Try to launch it in your browser (warning: extremely slow if you don't use state-of-the-art browser). Or just watch the YouTube video. Impressive, isn't it?

When I saw Monster demo for the time, I thought it would be cool to be able to run it as a Qt application. Porting the demo from JavaScript to C++/Qt is one way to do it, but to make the challenge even more painful, I decided to run the monster.js code directly (warning: it's minified, better check Dean's open-source 3-D engine behind the demo). There are tons of ways to do, I almost tried every possible permutations. In the end, I managed to run Monster Evolution smoothly, at more than 25 fps on a fairly modern machine. What was to be just a quick hack turned into a struggling but delirious adventure, resulting in a three-installment series.

For the YouTube generation, here is the time-lapsed screencast (if you prefer, grab the 3 MB AVI).

In the first part, The QtScript Menace, I used Qt's built-in ECMAScript interpreter to run the demo. The performance was not my main concern (though it gave me the chance of using our work-in-progress Qt Script version that uses JavaScriptCore as the back-end), rather the trick on how to run it with as little code as possible. I ended up with a hackish pure JavaScript implementation of the canvas object, along with few lines of glue code, using Qt Script's feature of making a QObject instance available to the script engine. Surprisingly, it works pretty well. It downloads the JavaScript code from the Internet, setups some stuff and then runs it. For a program comprises 240 lines of C++ and 140 line of JavaScript, I am pretty happy.

For the second attempt, Attack of the SquirrelFish, JavaScriptCore was chosen as the engine that powers the demo, used via QtWebKit. Again the same trick was employed, with the glue code now relies on QWebFrame's addToJavaScriptWindowObject and evaluateJavaScript. This requires only minimal changes, with an improved performance as the result (significant and noticeable), especially when JIT is available.

The saga was closed with the third episode, Revenge of the Cylinders. This time the victim was V8, the JavaScript engine which powers Google Chrome. Again, the code change was minimal, consider that V8 glue code to this little Qt application needs to be written manually. Of course this requires you to build V8, I have included the instructions (works on Linux, Mac, Windows) in the accompanying README on how to do that.

Feel free to try all three methods and let us know the frame-per-second speed-up that you get!

what you see is important, how you see it is even more

In case you miss it, Benjamin just added Google Suggest to Arora, within hours after I showed how to do it in Qt Labs. His BSD-licensed Google Suggest implementation is very lightweight, it is pretty trivial to integrate it to most common applications.

Screenshot follows (click to enlarge):

I was blindfolded but now I'm seeing

Two (old) tricks for the price of one. Well, since it takes two to Tango anyway.

The first is to make your window movable by dragging, especially if the window does not have a title bar (remember the classic WinAmp?) or use a custom-drawn one (Google Chrome is the prominent example here). To make the challenge more difficult, no change to the main window code is allowed. To reveal the secret (which is a matter of using event filtering properly), go to my Qt Labs blog entry: Moving top-level window by dragging.

To see it in action, peek at the following screencast (alternatives: YouTube, blip.tv, 3.7 MB Ogg Theora).

The second is about Google Suggest. Almost all browsers have supported it. For a minimalistic example on how to do it, check out my other Qt Labs blog on Google Suggest made easy. The demo launches your default browser with the chosen search term, with or without autocompletion.

The proof lies in this short screencast (alternatives: YouTube, blip.tv, 450 KB Ogg Theora).

(It is evident that my default browser is Konqueror. I told you I am not that biased :-)

Now just like last time, who is going to turn this into a plasmoid?

won't you take me where the streetlights glow

Let's start with the screenshot (aka the proof):

For the full explanation, read what I wrote in our Qt Labs. Basically we just use Google Talk web app for iPhone, which is 100 percent HTML and JS. There is seldom an uglier hack than this.

Now, who is going to turn this into a plasmoid?

JavaScript speed race: reloaded

After the recent public beta release of Safari 4, it is time to do another round of JavaScript performance testing (see the last one I did). Here I compare the unstable/development releases of different web browsers, when running SunSpider benchmark (runs/minute) and V8 benchmark (raw score). The test machine is Lenovo T61 laptop armed with Intel Core2 Duo 2 GHz, 2 GB RAM running Windows XP Professional SP2. The results follow (longer is better):

Google Chrome 2.0 is the unstable version from the developer channel, where Chrome 1.0 is the stable one. Opera 10.0 Alpha unfortunately still does not include Carakan, the brand-new fast JavaScript engine from Opera. Firefox 3.1 is tested with TraceMonkey enabled, i.e. via javascript.options.jit.chrome set to true in about:config. Konqueror 4.2 is installed from the KDE Windows project (MSVC 2005 built), the latest stable version because its latest unstable still points to 4.1.96. For safety reason, Internet Explorer 8 runs inside Xenocode browser sandbox as the sandboxing overhead was found to be negligible. The laptop's power manager tool is set to give maximum performance, thus forcing the laptop to always runs at its maximum speed.

Gmail video chat

It does not work on Linux (yet), but this video and voice chat right inside Google Mail will be definitely a killer!

on CrossOver Chromium (a way for Chrome on Linux)

CrossOver Chromium is a nice and easy approach to run the famous Google Chrome browser under Linux (while waiting for the official Linux version and if you don't want to mess around with Wine). I tried it on my OpenSUSE machine, it works pretty well. There are minor glitches, like maximized window could not be restored anymore (because Chrome skips normal window management), a status bar that does not appear and disappear properly, the omnibox rendering problem, and similar other small annoyances. But all in all, for 11 days of work, it is an amazing achievement.

Checking its JavaScript performance using SunSpider, it is only up to 40% slower. However, it still feels smooth and fast. Definitely worth a try.

SpeedCrunch and git

I have shown before how to use git to manage your code hosted in Google Code Project Hosting and how to synchronize it (automatically) with a public git repository hosted in github. SpeedCrunch, your lovely desktop calculator, is an example of all this.

Flash back first. Due to an increasing demand, some time ago we (=Johan and I) decided that we should provide public Subversion repository for SpeedCrunch. Google Code was new but quickly became the popular choice, so Johan pulled the plug and imported the then latest version of the code. This happened 840 days ago. Fast forward to today. As of now, you can also get SpeedCrunch source code from github, it is available from http://github.com/ariya/speedcrunch/. It means you need as short as:

git clone git://github.com/ariya/speedcrunch.git

and voila! You get all commits since the first time the code was imported. For fun, try git log e3cddb :-). For practical reasons, right now I only push master and 0.10 branches, which correspond to the trunk and branches/0.10 in its Google Code subversion repository. The .git directory weighs at around 5 MB.

Of course, if you decide to fix bugs and make changes, just push your SpeedCrunch repository somewhere and (if Helder, the current maintainer, has no objection), I can merge into my github repository (if necessary, I would even cherry pick your changes). Think you can do better? Go ahead, sign up for github if you haven't done so (it's free!), then you can "fork" the repository easily. Just click on the button labeled fork. When you are happy with your own tree, use the pull request button (in your github repository) to notify me and we'll see what would happen.

Note: this public git repository is by no means the official one, as the official repository is still hosted in Google Code. It is fully synchronized, though. And by using git, I hope this can spark more contributions in term of new features, bug fixes, translations, etc.

Don't you just love choices?

dancing between github and subversion repository

As the next logical step after I wrote about easily using git to work with the subversion repository in Google Code Project Hosting, here is an idea to make your git repository available and still keep it synchronized (in both directions). The use case for my previous blog post is when your partners in crime still stick with subversion but you prefer to use git. Here it is extended further: some (not all) of your contributors start to realize how beautiful git is, try to use it, can't get rid of it and finally decide it to use only git from now on. It would be a crime to ask them to sync to the subversion repository themselves, hence the following dancing. Basically it works like this. In a Unix/Windows machine, do the usual cloning of a remote subversion repository and then push it to github. Your new git fans then clone the fresh git repository. It is amazingly simple, obvious and fast to do it this way.

First of all, register at github. You don't need anything except an email address.

Next, prepare your SSH key which will be used for authentication, this can be carried out in one minute, just follow the instructions. Go back to your account page, copy your public key and paste it there in the SSH Public Keys area. Then, use ssh-agent trick to skip typing your password every single time.

Tip: if you are on a Windows box and your msysgit does not come with the ssh-keygen tool, use the famous PuTTY (known as the terminal emulation with SSH support). In the package, there is a tool called PuTTYgen (PuTTY Key Generator). Simply launch this tool. Click on Generate button and move your mouse randomly for a few second. After that, type in a secret password in the Key passphrase and Confirm passphrase fields. Click the button Save public key and name the file as id_rsa.pub. Choose menu Conversion, Export OpenSSH key and name the file as id_rsa (without any extension). After that, navigate to your user directory, this is typically C:\Document and Settings\Username. Create a new directory named .ssh, if it does not exist yet. Move both id_rsa and id_rsa.pub to this .ssh directory. Now you are set. File id_rsa.pub contains your public key, so copy and paste it into your SSH Key in the github account page.

Now here comes the fun part: create a new repository. Just fill out a few fields and it is ready. Couldn't be simpler, could it?

At this stage, go to your local git working directory (i.e. the one cloned from a subversion repository) and do the following:

git remote add origin git@github.com:joesixpack/coolproject.git
git push origin master

by substituting joesixpack and coolproject with your github login name and the freshly created git repository. Wait a couple of seconds (or minutes), then basically your git repository, which is a clone of the remote subversion repository, is successfully pushed to github. Well done!

To keep both repositories synchronized, you can run a cron job that does the following:

git checkout master
git svn rebase
git svn dcommit
git push origin master

If you have branch(es) in the subversion repository, you still can do that. Just add few more commands and substitute master with your branch(es) name.

Tip: If accidently you push your local branch to github and now you want to remove it, use:

git push repository :heads/branchname

OK. So far so good. Now of course you do not work on a single machine, e.g. you may do the above steps in a Linux server but you would like to work on your Windows laptop. At this moment, you need to prepare another SSH key or just use the same key (e.g. copy the previous id_rsa and id_rsa.pub). Then it is a no-brainer to clone your repository:

git clone git@github.com:joesixpack/coolproject.git

Note: don't be surprised with the amazing speed of doing a git clone. Essentially, you get the whole repository (which contains the full history of the project) in a short period time, probably comparable to the time needed to check out from the subversion repository (which however gives you only some part of the changes history).

Awesome. In just few minutes, you have a git repository which can be synchronized with a remote repository (e.g. in Google Code project hosting). In addition, you can push this repository to github. And still, you can clone the repository in another machine for your pleasure. Now if you want other people to clone your repository, just tell them to do:

git clone git://github.com/joesixpack/coolproject.git
cd coolproject

Once they send patches to you or push their branches, you can do the merge into your git repository and push it to github. Due to the said cron job, the subversion repository (e.g. in Google Code) will get the changes as well. Every now and then, when other contributors commit some changes to the subversion repository, the changes will be also propagated to github. Both parties are happy.

Happy gitting!

Quick Start: using git (for Windows) with Google Code Project Hosting

Ideally everyone uses git, because just as Linus once wrote: Centralized works. It is just inferior.

And like what I expressed before, the project hosting feature of Google Code is a nice choice (much better than SourceForge) for doing collaborative works on open source projects. You have a project page, a wiki, a download space, an issue tracker, integrated statistics and mailing-list features, and of course a repository. However, up to now only subversion repository is offered. Likely because of the 80% folks reason.

That is surely not the end of the world. You can try to polish your growing git skills with that subversion repository by using git-svn. The idea is that you use git and then, once a while, you place the code in the subversion repository. This has several extra advantages than doing git only. First, there is a backup done by Google to your repository. In addition, other developers that know only how to use friendly GUI tools, e.g. TortoiseSVN, can get the code easily. And if they are the project members and contribute some code (through Subversion because that is what those poor guys are using), you can still merge their changes without pain to your master working branch. Also, your code is searchable with Google Code Search and this gives more exposure and promotes code sharing and reuse.

This short instruction is mainly targeted to "average" Windows developers who wants to use work offline using git and still are not afraid to use command-line, but not for the usual hard-core Linux geeks (who can easily recall the manpage of git even if you suddenly wake them in the middle of the night). For the latter, there are many posts that already cover it. Just so that you are aware, what is written below is not a replacement for the git-svn manual. In addition, suitably adjusted, it should also work with other types of subversion repositories beside Google Code Project Hosting's one, e.g. your company internal repository.

To get git, visit the msysgit project (which is, unsurprisingly, hosted on google code). Download the latest version that also includes git-svn, e.g. Git-preview20080301.exe at the time I write this. After that, double click the .exe file to install it. You will be presented with the installation wizard, just accept the default and continue clicking the Next button a couple of times until you finish. Usually it means you'll get git on C:\Program Files\Git and also you can right-click on Windows Explorer window to start doing some git magic from that active folder.

To initialize the git repository, from Windows Explorer folder tree, right click on a folder and choose the menu item Git Bash here. A console will open, here where you have type in the following:

git svn clone -s --username=joe.sixpack https://coolproject.googlecode.com/svn git

Of course, substitute joe.sixpack and coolproject with your Google Code user name and project name. The following message will show up:

Initialized empty Git repository in .git/
Authentication realm:  Google Code Subversion Repository
Password for 'joe.sixpack':

and then just enter the generated Google Code password for the subversion repository. If everything is fine, all the revisions in the remote Subversion repository of your project are being pulled to your local git repository. This may take a while, especially if your repository has years of history.

Note: On Windows, git-svn performance is just so-so. Maybe this will be improved in the future version. If suddenly you see git-svn fails at some point with the following error message:

 Cannot commit config file!
 config svn-remote.svn.branches-maxRev 116: command returned error: 4

then just retype your last clone command as git-svn would happily continue from where it stops (i.e. no need to pull from revision 1 again).

Now what you get is a subfolder called git (the last argument in the clone command that you typed before) which is your working folder and which contains the git repository (evidenced by a subfolder .git inside it). Switch to this git folder and you are ready for the subsequent steps.

To compact your git repository, run:

git gc

In principle, you need to do this only once a while. Here it is a good idea to do it because you just imported your whole subversion repository.

Tip: Because git repository is very compact, don't bother with disk space when you do the initial step of cloning. This is usually a point that is always repeated by your nearest git evangelist. To give an example, after cloning over 1300 revisions of SpeedCrunch source code, my git repository is only around 7 MB. On the other hand, a single subversion checkout (including all the branches) is already 51 MB. Mind you, that 7 MB contains all changes that have been committed during the history of the project vs 51 MB which is associated only with few subversion revisions only (trunk and several branches).

To start using git for your brand new cool feature, usually it is best to create a new branch for that particular feature. First, check all the branches that you might have using:

git branch -a

which gives something like:

* master
  0.6
  0.7
  0.8
  0.9
  tags/0.7
  tags/0.7-beta2
  tags/0.8
  tags/0.8-alpha
  tags/0.9
  trunk

where the star sign (*) indicates the current branch. The branch called master is created for you automatically, it is basically the local git branch to track the trunk version of the remote subversion repository.

Now create a new branch, e.g. joe/feature1, from master with the command:

git checkout -b joe/feature1 master

The name joe/feature1 is arbitrary. It won't be visible to the outside world because it is your local branch. So feel free use a naming scheme that suits you.

Time to have fun! In this branch, implement the feature that you love and do some coding there. Once you are happy, just commit it (to this branch) using:

git commit -a

Continue hacking on it until you are satisfied. Make as many commits as you like. The sky is the limit.

Finally, when you think the feature is rock-solid, to merge back your changes to master, do the following:

git checkout master
git merge joe/feature1

which means switching back again to the master branch and the apply all the changes that have been done in joe/feature1 branch. Simple and lovely, isn't it?

Now, what about the poor souls that still need to check out or update the code through the subversion repository in Google Code? Well, you still can push your changes there. To synchronize the remote subversion repository with your git master you need to do:

git svn dcommit

The other way around is perfectly possible as well. If your collaborators change something in the remote subversion repository, to keep your git master up to date just use:

git svn rebase

That is all. For more advanced techniques, refer to the git-svn manual. Don't forget to polish your git skills by reading the manual and tutorials as well as (of course) doing a lot of practices.

Tip: An alternative to the very first stage of cloning is just to populate the new git repository only with some latest revisions of remote Subversion repository. Use the following commands:

git svn init -s --username=joe.sixpack https://coolproject.googlecode.com/svn
git svn fetch -r 1300:HEAD
git gc

which will just give all the changes starting from revision 1300 to the last one (HEAD). This is of course not really recommended because you won't get access to the whole history of your Subversion repository, but it is still useful if your project is very large and you do not care with all those changes made in its prehistoric time. If you use this init+fetch method instead of clone, there is no subfolder created. Your working folder (and git repository) is where you did the init and fetch. Now you can continue the usual steps of creating a local branch, implementing your feature, synchronizing, and so on.

Don't you just love git?

Google Docs goes pink

Likely only today. And even the star becomes a heart.

Obligatory Google bugs

They are more dangerous than Seb's :-)