Posts Tagged ‘git’

Mercurial Bookmarks Revisited – Part I

Bookmarks is an extension to the Mercurial SCM, which adds git-like branches to Mercurial. The extension is distributed together with Mercurial.
Recently the extension has received a major update. Time to look back.

This is a series of blogposts that consists of three parts:

(1) Part I: History of Bookmarks
(2) Part II: Daily Bookmarking
(3) Part III: Pushable Bookmarks


Writing a hg to subversion gate

Using a decentralized version control system (DVCS) like Mercurial (hg) or Git as a client for Subversion is very common. With the unique features of a DVCS a developer can have both the features of offline development and local branching while still being able to push to a subversion server. This approach is often used in environments in which subversion is the given version control system. While the approach of using this bi-directional push and pull mechanism, provided by git-svn or hgsubversion, works perfectly for one developer, it has limitations working in a team using the usual DVCS push and pull concepts.

The following article will outline the current limitations of bi-directional dvcs to subversion bridges and shows a simple approach to implement a solution for a certain instance of the problem.


For those of you, who didn’t notice so far, in the last 6 month we worked on a more userfriendly and accessible page than the current mercurial website. Three weeks ago we launched which is quite similar to I hope you enjoy it

git2svn, a little bit of git voodoo.

Interacting between git and subversion is quite common. The git command git-svn can be used to import existing subversion repositories into git and commit synchronize commits between two repositories. While importing a subversion repository into git is common, importing an git repository into subversion is quite unusual. There are various tools to do so, but most of them require direct access to the svn repository. In fact it is possible to use git-svn to get that job done. Frankly it requires some git voodoo and knowledge of the graft-feature. We’ll do a sample import using grafts, but before we start, we’ll explain the theory behind the import.

Merge vs. Rebase – A deep dive into the mysteries of revision control

I remember the days when I started learning Git about two years ago. I crawled through all the available commands and read the man pages what they are for and I remember when I stumbled over rebase and stuck. After figuring out what it actually does, I start loving it, but didn’t understand it’s dangerousness until someday I somehow got duplicated commits after pulling from another repository. So let me explain what goes wrong and why merge and rebase are often misunderstood. I’ll also present a list of golden-rules about their usage. Before we start with explaining both commands, I would like to give you one of the most important rules, in case you don’t want to read the complete article.

Never rebase branches or trees that you pulled. Only rebase local branches.


A really unfriendly and not so fair approach to GIT vs. Mercurial

Okay, this is one of the posts I wanted to since about 1 year, but now, nearly 2 years after the first git vs. Mercurial blog post I finally made it to actually write a second time about this topic. A first notice: I won’t cover bazaar. I personally hate it with passion and think it is the worst approach to DVCS ever. Nevertheless git and Mercurial fight in the same game with the same weapons (unlike bzr which is just far behind).

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 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