Learning Git can be a bit daunting—concepts like the index, the abstract model of Git repositories as a directed acyclic graph, and commands like git-reset and git-rebase are hard to wrap your head around. Coming from CVS or Subversion, it is easy to think that Git is just weird, much like Lisp macros might confuse the average programmer. However, last year, Ted Ts’o wrote

[...] I see its potential as being greater than hg, and so while it definitely has some ease-of-use and documentation shortcomings, in the long run I think it has “more legs” than hg, [...]

Having gotten comfortable with Git, I definitely agree with this statement.

Compared to Mercurial, branching with Git is much easier. When developing features for Chord, I would use Mercurial’s patch queue extension to develop features piece-meal until they were ready to commit. I would edit the series file manually to rearrange commits, in particular to push out small bug-fixes. It is much easier to use topic branches or git-stash to arrange (and re-arrange) commits and do small fixes. Git’s view of branch heads as simply pointers to some commit on a commit graph and its constant tracking of your commit history with reflogs around allows you to develop without fear of losing your work, even when arranging things so that your published history is pretty. In Mercurial, last I checked (around version 0.9.4), branches in a single working tree were still somewhat confusing and hard to use.

Git also has excellent Subversion and Perforce front-ends. With git-svn and git-p4, you can mirror an existing repository (say, the official version control system at the office) into Git, develop using all of Git’s tools, then push changes neatly back into Subversion and Perforce. Mercurial has hgsvn but I haven’t used it and its documentation suggests that it can’t push changes back into Subversion; I don’t know of any Perforce front-ends for Mercurial.

Mercurial makes it extremely easy to serve up a repository, without requiring starting a daemon on any special ports. hg serve is all you need and you can efficiently clone a Mercurial repository over HTTP; Git uses a special protocol that runs over a dedicate port, making it somewhat less firewall friendly. Mercurial also better allows differences between the HEAD branch (aka tip) and your current working directory state—you can push into a repository with a working directory without confusing Mercurial; not so with Git. This means collaboration in Git requires a third copy of the repository for collecting commits (or requires that repositories be updated only by pull).

For most uses, Mercurial and Git are more-or-less interchangeable, especially with the usability improvements in versions 1.5 of Git and later. The most basic commands like status, diff, commit, and log behave very similarly (at first glance). Commands execute quickly, even for large trees. Both systems are very flexible with modules and scripts that bring most features to parity. For myself, having learned how to work with Git, I prefer the power Git offers with fast branches and powerful tools like reflogs and rebase. For the undecided, fortunately there are tools that convert repositories from Git to Mercurial and vice-versa, so other than mental switching costs, there is little to fear in choosing one or the other. I won’t be using Subversion or CVS any more if I can help it.

In a diatribe against OpenID titled, “Goodbye, Passwords. You aren’t a good defense”, Randall Stross argues (?) that the time for passwords has gone and (password-based) single sign on systems like OpenID are not going to fly. Let’s ignore the fact that while he claims “no security expert [he] could reach” thought passwords were a good idea, he names no actual experts in his column—could he not, for example, get a comment from Bruce Schneier, who has written extensively about the subject? By ignoring that, we would be less likely to conclude that perhaps that his column is just a front piece fed to him by the source he does cite, Kim Cameron. (The OpenID blog contains a somewhat more objective defense of the issue.) OpenID is still a long way from mainstream, however, and a site can do many things to improve their authentication security without it.

Session management allows users to participate in detection of password theft. For example, Google Mail now lets you manage authenticated sessions. Not only does GMail now explicitly inform you when and from where your account has been accessed recently (which many banking websites do as well and Unix login has done for years), it also lets you explicitly log-out those other sessions. This is great news for detecting and then dealing with password compromises. Google Mail also added a setting to ensure that your mail itself always goes over an encrypted connection. This lets you trade-off between the computational overhead of secrecy via encryption and performance—for users, the computational overhead of a single SSL connection is minimal and easily amortized over a day-long GMail connection.

Google’s approaches, however, still rely on your password. What if you are at an Internet café and want to check your e-mail but not risk losing the password that protects your AdSense account? FastMail has the solution: One-time and SMS passwords. This is a brilliant feature that I am surprised is not more widely available. Basically, FastMail offers a variety of options for generating temporary, disposable passwords. You can pre-create a list of single-use passwords that you keep safely in your wallet: even if the password is captured by a key-logger or shoulder-surfer, it can never be used again to authenticate you. You can also create, on-demand, a single-use password that is sent via SMS to your cellphone. These are great ways to protect your account while still being able to access it from anywhere.

Any web system must also deal with the inevitable forgotten password. ING Direct demonstrates how this can be handled efficiently and safely. Instead of the moronic question/answer systems that demand that you remember exact, case-sensitive answers to short answer questions, ING appears to ask you specific questions about your current billing address, and then some things from your credit report (like where you used to live or work). I remember the addresses of places I used to live and work; I can’t remember if I used to own a Subaru or an Outback. ING often feeds you wrong information to clue you in to a potential problem—enter an invalid saver ID and it will happily make up a name for you that’s not yours. And after jumping through these questions, you also have to prove access to a verified e-mail address. These are familiar, repeatable tasks that I feel work quite well.

Finally, the display of personalized phrases and images at login time help reduce the risk of phishing attacks, by authenticating the website to you. Yahoo! sets a cookie for this purpose, displaying text in a color of your choosing, for each computer you use—the browser policy of returning cookies only to the domains that set them ensures that you are connecting to the proper site. Vanguard and ING both link the custom image to your username. They trade-off the convenience of not having to worry about cookies on every computer for the potential risk of a man-in-the-middle attack. I’d imagine they’ve done the risk analysis studies to determine that this works out best.

It would greatly improve the security of most websites if they supported user session management, forced SSL, provided one-time passwords/SMS passwords, authenticated users using intelligent questions, and authenticated to users explicitly. While they may be foreign to users today, as they become more common and uniformly adopted, they will become as familiar as captchas but infinitely more useful.

Tim Ferriss argues that we can all approach mastery of many areas, that mastery can be achieved in less time than we think. He writes:

Generalists recognize that the 80/20 principle applies to skills: 20% of a language’s vocabulary will enable you to communicate and understand at least 80%, 20% of a dance like tango (lead and footwork) separates the novice from the pro, 20% of the moves in a sport account for 80% of the scoring, etc.

Of course, it takes more than 21 days to master a skill and daily practice is critical. You must constantly challenge yourself to do something difficult and to learn something new.

I find these challenges incredibly rewarding. Since I graduated college, I’ve taken up hobbies and skills outside my professional work—from yoga to photography; I continue to learn about about areas within my field, from tools like the hot version control system of the day to how to write an operating system. Some things I still want to learn include massage, menu planning, haircutting, jazz piano, … not to mention continuing to improve upon what I’ve already learned. But it is hard to find time to learn new things and keep up with old ones. Time management is something I have yet to fully master. I’m working on it.

Are you a master? No? Why not?