Git's DAG is just a bunch of branches

Eric Sink, a generally smart guy whose postings I've been reading for some time, has recently been working on a series of articles about Git.⁽¹⁾

Now, I think Eric is awesome. He writes generally good stuff, and he runs a bootstrapped software company, and people seem to like him, and he's a respectable guy. I hope to be as smart and successful as Eric some day.

I also respect that a lot of rather crazy people have noticed that he's being kind of hard on Git in his article series, and have been flaming the crap out of him.⁽²⁾

But.

But the last couple of articles have gotten a little... erroneous. First of all, let's acknowledge some things he says that are totally true: most users of version control do like the linear model just fine. The linear model does solve lots of problems. Git's user interface is incredibly obnoxious and confusing.⁽³⁾ Being able to rewrite revision history and make partial checkins is amazingly dangerous, and fun, and startlingly easy to horrendously misuse. And if you work for a Big Faceless Software Corporation, may God help you if your co-workers get their hands on such tools.

If you really feel you have to flame Eric, please don't flame him for saying any of those things. Stop for a minute, think about it, and realize he's actually right.

It's just that he's only telling half the story.

Anyway, I might not have bothered about this at all, except for his recent comments about the DAG. He claims that allowing developers to attach new commits anywhere they want in the tree is this terrible, confusing thing that nobody will understand and which can release untold pain and suffering upon the masses.

...but Git's DAG (directed acyclic graph) is just a bunch of branches. I admit it, I've never used SourceGear Vault, but... it has branches, right? Aren't branches just arbitrary points in a tree structure where development went off in two directions? Kind of... a fork? Where your "straight line" development, you know... branched?

The magical thing about Git's DAG is not that it branches and has lots of different leaf nodes. If your version control system does anything right, it can do that. Geez, RCS and CVS can do that just fine. (Ironically, Subversion can't, but I'll claim that it's the crazy one. Its every-branch-is-a-subdirectory model is certainly extremely rare.)

No, what makes the DAG in Git special is the way it joins the branches up again. The only difference between a tree structure and a more general DAG is that DAGs can join back up again. That's all. Before DVCSes came along, you could branch, but merging was a synthetic operation. All you could do was make more and more branches, and then, if you really wanted, find a way to copy the changes you made on one branch into another branch, which we called merging. After that, you could try to ignore the old branch, or even "delete" it (for varying definitions of "delete" depending on your VCS). But once you branched, that branch was its own completely independent set of history... forever.

The only thing special about Git's DAG is that you can join branches back together again. The merging operation is the same, Git just stores the fact that it happened. Merges in Git reduce confusion, because once you've merged, you'll never accidentally re-merge the same changes, and you never have to remember by hand which changes are which.

In short, I don't know anyone who has been confused by branching and merging in Git, at least no more than they've been confused by branching and merging in any other VCS. Confused by Git's user interface, sure, absolutely, every single person, every single time, until (if that person is very lucky) it finally clicks.

But the DAG concept, mind blowingly confusing? No. It's not even new enough to be confusing.

Footnote

⁽¹⁾ How much do you want to bet that the eventual conclusion to his series will be the announcement that the new version of his product now supports distributed version control, but is more user friendly than Git? Hey, go for it.

⁽²⁾ I've been thinking of writing an article that I'd call, "The Free Software Community is a Bunch of Weenies," in which I point out that back in the good old days, the only way free software weenies would flame you en masse is if you said something nice about Microsoft. Now you can get flamed for just about anything. Like when ext2resize ate all my data, for example, and it was obviously my fault. It appears that most Linux users now use Linux just so they can flame people, which makes me sad.

⁽³⁾ When I said "Git is the next Unix," I meant it in the bad ways as well as the good. Unix is 1) crazy, 2) not mainstream, 3) appealing to geeks, and 4) apparently unkillable. I expect Git will fill the same role in version control systems. Those who do not understand Git are doomed to reinvent it... poorly.