Experiencing git, from a Darcs POV

Well, we’ve moved the Ramaze repository to git this week.

I learned version control with Darcs a couple of years ago and have been trying to move to Mercurial, for our Ramaze code base which didn’t work out for me and some other devs.

This time around it seems like our switch will work out, no major issues with the way git operates and handles our code, no problems with uselessly logged merges (♥ rebase)…

However, my issues with git are mostly with its user interface on the command line, I’m no friend of things I cannot do on the CLI and so this is not easily fixed by switching to things like git-gui.

Commands i’ve used so far include: git-add -p, git-blame, git-branch, git-checkout, git-clone, git-commit, git-config, git-fetch, git-format-patch, git-fsck, git-gc, git-help, git-init, git-instaweb, git-log, git-mv, git-pull, git-push, git-rebase, git-remote, git-reset, git-rm, git-status, git-whatchanged

That’s just a small fraction of the available commands, but I get along with them quite good already.

What’s still causing me trouble is the weak mapping I can create between darcs and git, darcs is just really, really simple to use - even if you have never taken a look at their Theory of patches.

In git things are not as simple, you have to deal with things like local and remote branches and frequent merges between them. Where in Darcs you only have one working copy and a bunch of patches that represent the history and pristine state.

However, the Darcs’ outer simplicity and inner complexity is also its weakness, if you run into problems there is sometimes nothing left that you can do, I have encountered endless running operations, repositories larger than my RAM (fail!) or a curious mix of patches that showed up every so often and produced conflicts that were impossible to resolve in a way that worked in other repositories as well.

This is, however mostly no problem if you are handling small repositories, do your personal version control or use the recently released Darcs 2. Speaking of Darcs 2 however, I did encounter problems where the conversion of our Ramaze repository would have taken around 1 week of CPU time but it was incredibly fast using Darcs 1, most likely because the Version 1 kept a pristine directory in the _darcs directory and so didn’t have to calculate all the way up from patch 1 on every patch.

I may blame this on the (otherwise rather good) darcs-to-git script, but it was designed to run with Darcs 1, so I’ll take the blame on myself instead. I just recommend people who use the darcs-to-git script to convert their repository to old Darcs 1 and not hashed or full Darcs 2 format before running into the same issues and wasting a lot of time.

Now to the real reasons why we finally decided to move to git with Ramaze. First up comes (surprise, surprise) speed, Darcs doesn’t have it, once you have spent a whole hour getting a remote repository you may just as well use rsync or scp or wget -r and in any case you are faster, a simple pull can take up to a minute via ssh, half a minute Darcs simply sits there and tries to figure out the version of the remote repository, in Darcs 1 it even downloads all patches since the last tag before, finally, it finds out that there is nothing to pull. darcs annotate is another command that can take a very, very long time. If you are working local these things are hardly an issue, but if you try to collaborate with a lot of people, most of them using different versions of Darcs on different systems and by different methods it becomes obvious real soon that you have to rethink your approach.

I did stick with Darcs for a reason, despite these problems, that is the simple UI and that I learned version control with it. I don’t have a history using SVN or CVS, distributed version control runs through my veins. I do know that it’s not the perfect solution for everybody, but I’m mostly working in the open source area where sharing your code is essential. Darcs is reasonably cross-platform (although the necessity for building GHC on some systems is a major issue), it makes things simple on a CLI level, allowing people to contribute patches without any real knowledge of what’s going on.

As I mentioned before, Darcs provides you with the best user interface I have encountered so far, comfortable cherry picking on pull, record, revert, no need to hit the return key after every decision (some people say this is not Unixy, but I haven’t really been able to find any evidence their way is any better for anything), it does make a difference whether I have to say “y” or “y\n”, the return is simply not necessary. If I made a mistake I can just go back one hunk and correct the choice.

I will have to explore ‘git add -p’ and ‘git add -i’ a bit more, currently I’m mostly using the -p variant as it’s closer to the ‘darcs record’ equivalent.

Anyway, I’ll hopefully write more as I experience more.

Home again

I finally returned to home (my parents house in austria). Things changed, but most are still the same, so I can head home (the tokyo one) again without problems on friday. Just had to ping. I’m still alive :)

PS.: German keyboards are the death of programmers.

Be on time. Every time

Introducing Gmail Custom Time ™

RubyFools conference coming up

Well, wasting my time on a plane with writing here, bytes are patient.

On April 1st I’ll be finally going to the RubyFools conference.

Whitix: a simple operating system

I just stumbled upon whitix, operating system that features really nice ideas and worked immediately for me in qemu. According to their page:

Whitix is a 32-bit operating system for the Intel and AMD range of processors, licensed under the GNU GPL.

It’s 32bit only, but I hope they’ll fix that as long as the system is still young.

It seems like all the new operating systems are being developed for emulators first, my guess is that it provides a common platform for participants and also makes it nice to work on from an existing OS. Moving totally into a virtual machine is what I see as the next logical step as soon as computing power allows for it, completely writing for a virtual computer. That may be a dream for now, but I haven’t seen anything groundbreaking taking place in the realm of hardware that couldn’t be handled by such a layer, and it seems to work just fine already for things like xen.

Of course that’s only a dream and we won’t be there anytime soon, but it would make it possible for just about anybody to dive into OS development, which I find a very interesting area personally, but ensuring and providing support for different platforms just seems too time-intensive.

A little piece of future

This week I’m finally getting back to Europe for a change, I’m going to speak at the rubyfools Conference in Copenhagen and Oslo. Afterwards I will head to Austria to visit my family and friends, most of them haven’t seen since I left for Japan.

This will also be the day I stop working full-time for my old company weez and will continue as consultant so I can handle more projects at once. I’m already having quite interesting offers, as ramaze gains popularity it also needs increased support and hands-on help. We are quite successful at providing solutions to problems of people asking in IRC and the mailing list, I would like to expand that, writing more documentation, tutorials and helpers.

This website is going to be part of this process, providing a platform where I can write down ideas and receive feedback. No, feedback is not possible through comments, whoever has to say something interesting will know where to direct it to.

Regarding the conference though, I’m a bit nervous, there are a couple of other people presenting their outstanding frameworks and I really hope the form of presentation I chose is going to be doable. In anticipation of problems I’ve done also an old-style one using only OOo, but I do hope they will let me connect my notebook and hack away.

As usual, we will see how things turn out.

Maruku

One library in Ruby i really like: maruku. It’s a markdown parser with a couple of really nifty extras. I find a use for markdown in many places. Content management, blog comments, todo lists and converting README to HTML are only a few.

The markdown dingus invites you to try converting a bit of markdown syntax into real HTML. I’m not exactly sure what I don’t quite like about textile, but maybe Markdown just fits the way i write text anyway.

What is vy

Have a look at this neat page: what is vy

vy makes sites by converting text snippets to valid html5 and interlinking their filenames. dvy is a Rack application rendering vy dynamically.

Very nifty, another hack by the legendary Christian Neukirchen.

Hello, World!

This is my first entry in yet another attempt to write a blog that even I would want to post in.

Some ruby code, highlighted by the syntax gem:

require 'ramaze'

# Some comment
class MainController < Ramaze::Controller
  def index(interpolation = 'World!')
    "Hello, #{interpolation}"
    100_000 + 1000
    /regular #{expression} \d+/
    "Hello, World!"
  end
end

Ramaze.start :adapter => :thin, :middleware => true

About MoxonoM

MoxonoM is what i name every manifestation of my blogs. I thought up that name after a few of searches on google to find an unique term a couple of years ago (maybe around 2000). Since then I've had a new blog every year and it's almost a tradition for me to write a new blog around Spring.

Every time I'm trying to use new techniques that I have not learned yet, since I believe the real art of programming is in creating new things.

Unfortunately that isn't easy when speaking in terms of my work as programmer, existing systems have to be taken into account and one has to adapt new components in a consistent manner. Maintainability almost always beats Novelty.

This instance of MoxonoM uses a flat file system as database, organized into files that are written in a slightly modified markdown syntax (I only added a header to the files for meta data like tags and time). The web-framework is of course ramaze.

• Previous blogs have been using:

  • PHP & MySQL (different blog engines heavily modified or written from scratch)
  • Nitro & Og on Postgresql
  • Ramaze & Og on sqlite
  • Ramaze & Sequel on sqlite3

But this time I find it a fun challenge to build a well performing system on nothing but plain text and the two images you can see in the top of this page.

For people using Internet Explorer, please don't ask me to make this site display correctly in your abomination of browser and wait for IE8, I heard they are actually going to adhere to standards in that Version. In the meanwhile you can use firefox.

Thanks for tuning in, let's see how long this MoxonoM is going to last.