In your .zshrc add the following line

RPROMPT='[%?]'

This will give you the last exit status on the right site of your shell.

My zsh now looks like this (with the additional stuff)

buenosaires:~/dev/c/git.git/>                                         (next)[1]


WARNING: This is the most subjective, most pointless approach to this topic ever. I didn’t read it myself a second time, I just published it.

I will start the same way as last time:

git
Git is a decentralized version control system written by Linus Torvalds to replace bitkeeper as the version control system of choice for the kernel because of licensing issues (okay I know this is the short story and it was much more complex and you can write a thousand lines about that, but it’s enough for most people). Git is designed to be fast. Everthing is optimized in that way. It contains a huge C written core with a lot of bash and perl scripts around it. A few years ago the C written part formed the so called plumbing. Nowadays the git community tries to replace high-level commands written in bash and perl that call the plumbing commands with c-written code to get a more consistent code base.
Let’s make a long story short:
Git is powerful. Awesome powerful. This is true since git’s beginning, but back then it lacks a good interface and the git community did a great job in improving the horrible interface git had once. Git is still awesomely fast. Commits, bisecting, everything works like a charm particularly on big projects like the kernel. They can rewrite history, they are doing a great job in helping intergrators to apply patches, reviewing them, and pushing to multiple sources. Everything about git is really unique, their focus on a powerful command set, their branching support and their targeted audience. I want to talk a little bit about that fancy branching support. Frankly, every version control system, even the 3rd generation decentralized ones have a pretty conservative way of doing branching by giving every changeset a name that the changeset belongs to (at least this is true for mercurial, and called named branches there). Git just gives a sh** about that and takes a version control branch the same way as a tree branch. It’s just an unnamed branch of the DAC. This gives you the awesome possibility to great huge set of local branches, to merge, rebase them without any bigger problem or even just discard them (actually that is one of the biggest problems in mercurials bookmarks implementation). Another just great feature in git is the staging area. You can stage hunks, as a virtual repository that is used to actually commit the ‘selected’ changesets. That’s awesome and I’m really missing that in most of the version control systems that I use. The idea of a staging area is just a huge win for git. It’s so incredible powerful. Okay to put it in a nutshell: git is just awesome, but….

There is Mercurial.
Okay some kind of a warning in advance: I contributed two well known extensions to Mercurial, I hang around in their chatroom and I think that I’m a well known part of the community. Nevertheless if you talk about Mercurial and compare it with git you have to take care. Mercurial is by far not as powerful as git, and…that is just the best think about Mercurial. Matt really keeps it simple and clear for everybody. it’s so incredible easy to understand in the first place. There are no weird commands with a thousand of flags. Okay I try to be fair. Mercurial is much less powerful than git in the first place. Because it tries to keep everything simple. There is no rebase, no cheap branching, no staging area. But there are extensions. You can learn Mercurial and know all it’s commands within 24h. They are really easy to learn, and not powerful, but they can be extended, by a large range of extensions. You can have cheap branching (bookmarks), you can have kind of a staging area (record extension), you can have patch management on top (mq) and much more. With all those extensions, Mercurial is as hard to learn as learning all git commands (which frankly is not necessary at all), but it’s more of a evolutionary approach. I know a thousand people who say that learning git is as easy. Okay, no problem. I don’t think so but it doesn’t matter, but frankly, git is missing 2 big points. Windows and an application integration: If you live in your nice Linux/BSD/foo world you are right. Git is awesome, but come on, I don’t have a freaky Windows machine, but I know that 80% of all people and more than 50% of all programmers use Windows. No they are not these bad, not geeky enough people. They are the real programmers. Those who are not freaks and take programming as a job. They don’t care (and thats good) about their environment, they just want to get things done and want to earn money. That good. And even that is not quite true for most of them, they do their stuff just faster on Windows than on Linux, therefore it’s better for them to use Windows. Okay, you might argue, but there is mysysgit and it’s even part of official git. Oh nice arguement, but frankly, junio doesn’t provide Windows binary, there is no official site to get them from, and ….. git daemon still doesn’t work perfectly nor does git-svn. It just sucks. Big -1 from me for that one.
The second pint is the worse git internal design. It’s soooo unix style. It’s cool for people that love Unix (like I do), who pipe around at least 3 commands, and know that I it starts to get funny if you pipe around 5 commands. But most of the developer want to use a nice integrated version control system. They don’t like to use fancy command line stuff with a thousand of flags, they want to do click&click (the german expression would be ‘klicky-bunti’). They want to have it integrated in their Eclipse, their NetBeans, Visual Studio, their Windows explorer and so on, and frankly, git does a poor job in that area. I know there is an eclipse plugin (but the mercurial one is stilll a thousand times better), and all this fancy stuff, but what do they do, damn, they have to parse the shell output. This means either git will never ever change their shell output (which would be sad, e.g. I hate the # in git status), or they will break older stuff. Mercurail on the other side is really easy to interface with. Okay you need python but that’s all. Everything else is just smooth. It’s easy to handle, it’s easy to integrate, it just works fine. Git really does a bad job on that. And the git community knows it. That’s why they start their libgit, and libgit2 project, because they know something like a git library is needed.

Okay it’s late and I want to finish that without reading it a second time, no frankly, this time I want to be completely unfair, without any objective argument: So here comes my final words, make them:

If you like to play with software, if you really like to have the power, go for git, if you use Linux, even better, go for it, there is nothing equal to the power and the fun you can have with Git. You can be a thousand times more productive. But if you, or people in your team are not tech-geeks. If you use Guis and want to use Windows, believe me, you better use Mercurial. I really love both systems (as long as you don’t use bzr even SVN is fine), but in this use case Mercurial is just better. Think about it.

shame on myself: song for this post: This is the life by Amy MacDonald

Well now after 2 years of blogging I took another look at a WordPress and I must admit that I’m impressed by the clean admin interface and all the nice eye-candy. There are also tons of features that I like to use. So that’s why I decided to finally switch over to WordPress. I hope that my rss redirection will work for most of the people. For sure a lot of links on the web will just link into nowhere, but as I guess most of the links out there are not long-living, I frankly don’t care about that (But I care about the feeds, so give me feedback if you encounter problems).

The most notable change is the design. As I do not have the time to port my selfmade s9y design so far, I stick with a standard theme. Personally, I liked the old one more, but I was told by annoyed people, who had to scroll all the way down to the first article, that the big picture at the beginning wasn’t that good at all.

1. I leared PHP because I wanted to write a form mailer for a website.
2. When I was 13 years old, I spend a lot of time on a city network called RivalNet, causing a telephone bill of 600DM. There were no flatrates at that time.
3. I studied analytical philosophy for 6 months.
4. I make coffee the old-fashioned way by throwing hot-water through the coffee filter. My favorite sort is Jamaican Blue Mountain
5. I fear of dogs, seriously.
6. I started reading “Das Kapital” from Marx when I was 18, but still not finished it. Nevertheless, I still insist to call it a book that I’m currently reading.
7. My last name is spanish but I don’t speak castilian.

And here are the rules I’m supposed to pass on to the following bloggers:

• Link your original tagger(s), and list these rules on your blog.
• Share seven facts about yourself in the post – some random, some weird.
• Tag seven people at the end of your post by leaving their names and the links to their blogs.
• Let them know they’ve been tagged by leaving a comment on their blogs and/or Twitter.

And as for chaining, in no particularly significant order:

• Pierre A. Joye for doing awesome PHP windows work
• Thorsten Rinne for the invitation to Augsburg
• Ulf Wendel
• Zoe Slattery for helping to improve PHP’s quality
• Wolfram Kriesing
• Jan Lehnardt for his inspiring criticism
• Stefan Esser

Na dadurch kommt es natürlich, dass wir branchen, mergen, branchen, mergen und hoffen das wir keine Abhängigkeit vergessen haben. Aber nebenbei braucht unser Rosenheimcop noch die Refactoring Änderungen, dummerweise aber gleichzeitig auch den alten Code. Also patch und diff ausgepackt und von Branch zu Branch geschoben und commited.

Nein mal im Ernst. Endlich mal ein Fall bei dem dezentrale Systeme Sinn machen und deutlich weniger Schmerzen bereiten. Jeder Entwickler kann selbst bestimmen welche Abhängigkeiten er hat und wie er sie auflöst, indem er von jemand anderes pulled. Wenn ein Paket released werden muss, dann gibt es auch keine Commit-Stops mehr oder keine Verschieben weil die Tests nicht laufen. Dann fliegt das Feature raus. Da man sich aussuchen kann von welchen Entwicklern man die Features übernimmt, und diese auch selbst entscheiden können, welche Features es in den Hauptzweig schaffen, ist man einfach flexibler und schneller. Da kann man nur Looser und unseren Italiener mit nerven. Immer mit der Nadel durch’s Chitin. Agil und DVCS passen irgendwie.

Besser mal wieder die Robe ablegen und im Geheimen infiltrieren.