Beautifying commits with git

When you look at our Subversion log, you’d often see revisions containing multiple topics, which is something I don’t particularly like. The main problem is merging patches. The moment you cramp up multiple things into a single commit, you are doomed should you ever decide to merge one of the things into another branch.

Because it’s such an easy thing to do, I began committing really, really often in git, but whenever I was writing the changes back to subversion, I’ve used merge –squash as to not clutter the main revision history with abandoned attempts at fixing a problem or implementing a feature.

So in essence, this meant that by using git, I was working against my usual goals: The actual commits to SVN were larger than before which is the exact opposite thing of how I’d want the repository to look.

I’ve lived with that, until I learned about the interactive mode of git add.

Beginners with git (at least those coming from subversion and friends) always struggle to really get the concept of the index and usually just git commit –a when committing changes.

This does exactly the same thing as a svn commit would do: It takes all changes you made to your working copy and commits them to the repository. This also means that the smallest unit of change you can track is the state of the working copy itself.

To do finer grained commits, you can git add a file and commit that, which is the same as svn status followed by some grep and awk magic.

But even a file is too large a unit for a commit if you ask me. When you implement feature X, it’s possible if not very probable, that you fix bugs a and b and extend the interface I to make the feature Y work – a feature on which X depends.

Bugfixes, interface changes, subfeatures. A git commit –a will mash them all together. A git add per file will mash some of them together. Unless you are really really careful and cleanly only do one thing at a time, but in the end that’s now how reality works.

It may very well be that you discover bug b after having written a good amount of code for feature Y and that both Y and b are in the same file. Now you have to either back out b again, commit Y and reapply b or you just commit Y and b in one go, making it very hard to later just merge b into a maintenance branch because you’d also get Y which you would not want to.

But backing out already written code to make a commit? This is not a productive workflow. I could never make myself do something like that, let alone my coworkers. Aside of that, it’s yet another cause to create errors.

This is where the git index shines. Git tracks content. The index is a stage area where you store content you whish to later commit to the repository. Content isn’t bound to a file. It’s just content. By help of the index, you can incrementally collect single changes in different files, assemble them to a complete package and commit that to the repository.

As the index is tracking content and not files, you can add parts of files to it. This solves the problems outlined above.

So once I have completed Feature X, and assuming I could do it in one quick go, then I run git add with the –i argument. Now I see a list of changed files in my working copy. Using the patch-command, I can decide, hunk per hunk, whether it should be included in the index or not. Once I’m done, I exit the tool using 7. Then I run git commit1) to commit all the changes I’ve put into the index.

Remember: This is not done per file, but per line in the file. This way I can separate all the changes in my working copy, bug a and b, feature Y and X into single commits and commit them separately.

With a clean history like that, I can consequently merge the feature branch without —squash, thus keeping the history when dcommiting to subversion, finally producing something that can easily be merged around and tracked.

This is yet another feature of git that, after you get used to it, makes this VCS shine even more than everything else I’ve seen so far.

Git is fun indeed.

1) and not git commit -a which would destroy all the fine-grained plucking of lines you just did – trust me: I know. Now.

Epic SSL fail

Today when I tried to use the fancy SSL VPN access a customer provided me with, I came across this epic fail:

Of all the things that can be wrong in a SSL certificate, this certificate manages to get them wrong. The self-signed(1) certificate was issued for the wrong host name(2) and it has expired(3) quite some time ago.

Granted: In this case the issue of trust is more or less constrained to the server to know who I am (I wasn’t intending on transferring any amount of sensitive data), but still – when you self-sign your certificate, the cost of issuing one for the correct host or issuing one with a very long validity becomes a non-issue.

Anyways – I had a laugh. And now you can have one too.

What sucks about the Touch Diamond

Contrary to all thinking and common-sense I’ve displayed in my «Which phone for me?»-post, I went and bought the Touch Diamond. The perspective of having a hackable device with high resolution, GPS and voip capability and flawlessly working Exchange-Synchronization finally pushed me over – oh and of course I just like new gadgets to try out.

In my dream world, the Touch would even replace my iPod Touch as a video player and bathtub browser, so I could go back to my old Nano for podcasts.

Unfortunately, the Touch is not much more than any other Windows Mobile phone with all the suckage and half-working features they usually come with. Here’s the list:

  • VoIP is a no-go. The firmware of the Touch is crippled and does not provide Windows Mobile 6+ SIP support, Skype doesn’t run on Windows Mobile 6.1, but all that doesn’t matter anway because none of the Voip-Solutions actually use the speakerphone. You can only get VoIP sound on the amplified speaker on the back of the phone – or you use a headset at which time, the thing isn’t better than any other VoIP solution at my disposal.
  • GPS is a no go as the Diamond takes *ages* to find a signal and it’s really fiddly to get it to work – even just in the integrated Google maps application.
  • Typing anything is really hard despite HTC really trying. Whichever input method you chose, you lose: The Windows Mobile native solutions only work with the pen and the HTC keypads are too large for the applications to remain really usable. Writing SMSes takes me so much longer than every other smart phone I’ve tried before.
  • T9 is a nice idea, but here and then, you need to enter some special chars. Like dots. Too bad that they are hidden behind another menu – especially the dot.
  • This TouchFLO 3D-thingie sounds nice on the web and in all the demonstrations, but it sucks anway, mainly because it’s slow as hell. The iPhone interface doesn’t just look good, it’s also responsive, which is where HTC fails. Writing an SMS message takes *minutes* when you combine the embarrassingly slow loading time of the SMS app with the incredibly fiddly text input system.
  • You only get a German T9 with the German version of the Firmware which has probably been translated using Google Translation or Babelfish.
  • The worst idea ever from a consumer perspective was that stupid ExtUSB connector. Aside of the fact that you’d practically have to buy an extra cable to sync from home and the office, you also need another extra cable if you want to plug in decent headphones. The ones coming with the device are unusable and it’s impossible to plug better ones. Also, the needed adapter cable is currently not available to buy anywhere I looked.
  • The screen, while having a nice DPI count is too small to be usable for earnest web browsing. Why does windows mobile have to paint everything four times as large when there are four times as many pixels available?
  • Finger gestures just don’t work on a touch sensitive display, no matter how much they try. At least they don’t work once you are used to the responsiveness and accuracy of an iPhone (or iPod touch).
  • The built-in opera browser, while looking nice and providing a much better page zoom feature than the iPod Touch also is unusable because it’s much too slow.

So instead of having a possible iPhone killer in my pocket, I have a phone that provides around zero more actually usable functionality than my previous W880i and yet is much slower, crashier, larger and heavier than the old solution.

Here’s the old feature comparison table listing the features I tought the touch would have as opposed to the features the touch actually has:

assumed actually
Phone usage
Quick dialing of arbitrary numbers (the phone application takes around 20 seconds to load, the buttons are totally unresponsive)
Acceptable battery life (more than two days) ? yes. Actually yes. 4 days is not bad.
usable as modem yes yes
usable while not looking at the device limited not at all mainly because of the laggyness of the interface
quick writing of SMS messages it’s much, much worse than anticipated.
Sending and receiving of MMS messages yes not really. Sending pictures is annoying as hell and everything is terribly slow.
PIM usage
synchronizes with google calendar/contacts
synchronizes with Outlook yes yes
usable calendar yes very, very slow
usable todo list yes slow
media player usage
integrates into current iTunes based podcast workflow
straight forward audio playing interface
straight forward video playing interface
acceptable video player yes no. No sound due to no way to plug my own headphones.
ssh client yes not really. putty doesn’t quite work right on VGA Winmob 6.1
skype client yes no. a) it doesn’t work and b) it would require headset usage as skype is unable to use the speakerphone.
OperaMini (browser usable on GSM) yes limited. No softkeys and touch-buttons too small to reliably hit.
WLAN-Browser yes no. Too slow, Screen real estate too limited.

Now tell me how this could be called progress.

I’m giving this thing until the end of the week. Maybe I get used to its deficiencies in the matters of interface speed. If not, it’s gone. As is the prospective of me buying any other Windows Mobile phone. Ever.

Sorry for the rant, but it had to be.

Mozilla Weave 0.2

I have quite many computers I use regularely, on all of which runs Firefox. Of course I’ve accumulated quite a lot of bookmarks, passwords and “keep me logged in”-cookies.

During my use of FF2, I’ve come across Google Browser Sync which was incredibly useful, albeit a bit unstable here and then, so last Christmas, I was very happy to see the prototype of Mozilla Weave to be released. It promised the same feature set as Google Browser Sync, but build from the makers of the browser on an open architecture.

I have been a user of Weave ever since and it was even more inconsistent in availability than what Google Browser Sync ever provided, but at least it was just the server not working, not affecting the client which GBS did here and then, which made me lose parts or all of my bookmarks.

Over time though, Weave got better and better and with todays 0.2 release, the installation and setup process actually got streamlined enough so that I can recommend the tool to anybody using more than one PC at any time.

Especially with the improved bookmarking functionality we got in Firefox 3, synchroniuzing bookmarks has become really important. I’m very happy to see a solution for this problem and I’m overjoyed that the solution is as open as weave is.

Congratulations, Mozilla Team!