Why Git Ain’t Better Than X

http://unspecified.wordpress.com/2010/03/26/why-git-aint-better-than-x/

by skorks • 16 years ago

28 42 16 years ago

unspecified.wordpress.com

micampe• 16 years ago

> So I don’t need to mentally deal with repositories vs branches, I just store my large projects in a shared repo, and it’s all good.

And here I was thinking he was going to explain why it's better to have them separate. If I must decide if I need a repository before creating branches, to me it means exactly I do have to deal with repositories vs branches.

Deestan• 16 years ago

> I haven’t used Mercurial, but this page indicates that the basic “clone” command does a full expensive branch, while the “branch” command does a cheap local branch. So this argument only applies to non-distributed VCSes.

I don't know how branches work in Bazaar, but Git branches are cheaper than Mercurial's when you factor in administrative overhead.

Local Mercurial branches aren't disposable, like Git's are. In Git, I often whip up and subsequently dismiss 3-4 branches when tidying up my repository history (for example when I committed something in the wrong place, committed with wrong log message, etc...). Mercurial branches live forever in the repository graph and I have to explicitly "close" them, while in Git I just forget about them and the repository does too.

gecko• 16 years ago

Mercurial actually has lightweight branches like Git; they're just anonymous, as in Monotone, not named like Git. There's an extension for Mercurial, called bookmarks, that allows you to name your anonymous heads, giving you Git-equivalent functionality.

You're correct that Mercurial's (IMHO badly-named "branch" command) is much heavier-weight than Git branching. I consider them closer to changeset labels than branches.

prog4• 16 years ago

bzr has the bzr-colo plugin to support co-located branches. Like I said in another comment, I think bzr, git and hg are comparable and there isn't a clear winner (and there need not be).

https://launchpad.net/bzr-colo

durin422• 16 years ago

Git's branches aren't _branches_ per se. They're movable references to heads, and there's no indication of a commit having been done on a branch once it's merged and the ref deleted.

If you want that workflow in Mercurial, use bookmarks. Some work is left to make bookmarks pushable, but it's going to be done, as many people want that feature.

dlsspy5• 16 years ago

Don't delude yourself that there's anything correct about storing the name of a branch in a commit, or that that's what makes up a proper branch.

When I receive a changeset in mercurial and see that it was made on a branch called "dev", that means nothing to me. When I get changes from several locations and they all say it was made on "dev", that helps me even less.

If it's actually important to you to know that a change was done on a branch called "dev" (and I doubt it ever will be), it's fairly easy to know just by examining the merge commit that brought it in.

In practice, I'd say it's just confusing. I wrote "hg log -b" initially for viewing logs only within a branch. As it turns out, you have to be really careful to name your branches since they can be reused (or worse as shown above) and it's very difficult to figure out whether a change occurred on a given branch or a different branch that had the same name.

pieter• 16 years ago

Good to hear Bazaar speeds have improved. When I tried using it, it was painfully slow, taking 20-30 seconds for a simple 'bzr log'.

prog4• 16 years ago

> When I tried using it, it was painfully slow, taking 20-30 seconds for a simple 'bzr log'.

When did you use it? On what history size? bzr 2.x series is quite fast.

dlsspy5• 16 years ago

Here's the difference between

bzr log on my clone of emacs:

    23.040u 1.518s 0:25.31 96.9%	0+0k 0+73io 0pf+0w

git log on my clone of emacs:

    2.197u 0.226s 0:02.89 83.3%	0+0k 36+14io 0pf+0w

loup-vaillant2• 16 years ago

He doesn't mention Darcs. Is this system so irrelevant? That would be too bad, I love relatively independence of it's patches. (Plus, the UI is really good at reminding you what you could have forgotten.)

durin422• 16 years ago

In my experience it doesn't take too long to find a pair of patches that commute which actually let you checkout a broken tree state. It's nice in theory, but in practice the DAG properties of the "mainline" DVCSes are very useful so that you can have guarantees about the non-brokenness of every point in the tree.

I think there's a lot of good to be had for commuting patches during code review, before they're final, but once finalized, they make the most sense in a DAG.

applicative• 16 years ago

Isn't it obvious that two patches in, say, different files might repair the same bug, but in incompatible ways? --It's the nature of programming, everything is connected. But they won't depend on each other from the point of view of the VCS, of course. If I pull and apply both, things will go wrong. Isn't this possible in all systems? I can always apply my way into a broken system.

When I have things right, and it compiles and I'm ready, I `darcs tag` -- for example. There are many ways of referring to patch-piles as adequate to compile together.

Though it's clear that `darcs` isn't good for all purposes, at least in its present form -- I don't think anyone says it is -- it is excellent for many; certainly almost everything up on GitHub would do better with `darcs`.

The most important advantage of it, it seems to me, is the complete transparency of the process and the underlying model; it is completely missing the black box aspect of something like `git`. People rightly praise many of the features of `git`, which I use, with amazement, in connection with some projects I help with. But I feel that all the enthusiasm for it is a bit like enthusiasm for something like Word, or some similar monster GUI program, on the part of people who have no idea what it's doing, how it goes about it; and all `git` tutorials are like tutorials for people about how to use Word. Learning new combinations of commands, is like learning about esoteric drop down panels in Word. --Though I suppose one can't blame `git` for the incredible tiresomeness of its enthusiasts.

xtho• 16 years ago

I personally don't care if X is 1ms faster than Y, I wish though the developer of X and Y would agree on common command-line arguments and workflow (and hide the details from me) so that I wouldn't have to write my own wrapper.

cookiecaper2• 16 years ago

The author claims that a 10x speed differential is inconsequential. I don't agree. Note that in his sampling, things were already taking 2-3 seconds on a relatively small repository. What happens when you get to the size where a git diff takes 2-3 seconds? Does bzr take 20-30? Surely that's not acceptable.

I understand that people can go overboard on the optimization, and can ignore more important things because of misleading or unimportant benchmarks, but there is something to be said for speed when it's taken on balance.

This article didn't point out any reason I would trade git for the much slower Bazaar, just said that Bazaar is not as bad as it looks on the Git is Better Than X website. That's not really a very convincing argument if I'm already using git.

astine• 16 years ago

On small projects like many of the ones on Github, the difference in speed doesn't really make a difference. But when you get to really large projects, like the ones git was originally made for, it really does. Not everyone works on huge projects, but some of us do. The question you need to ask yourself is: "Is this project going to be large enough for it to matter?" That's hard to say.

skybrian2• 16 years ago

It's amusing to hear the common myth that the Linux kernel is a huge project. No, a huge project is something like Gentoo or Ubuntu. Try to put all the source code for every package in a Linux distribution into a single Git repository and it (obviously) will fall over, because it would be tough to fit that on one machine. So if you're using Git, the best practice is "don't do that, then."

But I work at a large company where all the source code is in a single repostory. Being able to do a partial checkout (your package and its dependencies, on the head branch only) is essential for us and it's not a workflow Git supports at all.

I do agree, however, that Git is fast enough for any open source project out there. It's just not scalable to large organizations.

stevelosh2• 16 years ago

> This article didn't point out any reason I would trade git for the much slower Bazaar, just said that Bazaar is not as bad as it looks on the Git is Better Than X website. That's not really a very convincing argument if I'm already using git.

I'm guessing that's why the article is titled "Why Git Ain't Better Than X" and not "Why Bazaar is Better Than Git"...

cookiecaper2• 16 years ago

Well, it doesn't show that Git isn't better, it just shows that Bazaar isn't as bad as it seems on that site. Probably just because of updates to bzr since it was made.

ableal2• 16 years ago

A couple of weeks ago (apropos http://news.ycombinator.com/item?id=1180434) I looked up the 'advertising' at http://doc.bazaar.canonical.com/migration/en/why-switch-to-b...

For v2.0+, they quote 1.0 sec commits on the Firefox 3.5 repo test (vs. 1.1 for hg, 0.35 for git).

[Pointers to binary data performance figures (e.g. repo size deltas vs. SVN, etc.) gratefully accepted]

jobenjo• 16 years ago

We've been using bazaar at Fluther for a while and I have to agree with the author's sentiment for the most part.

The whole "Git is better" thing annoys me. Dvcs _are_ better, but I think it's mostly a wash between bzr, hg, and git. Yes, bzr is slower here and there (used to be annoying, now it's fast enough that it's a basically a non-issue). The parts I like more than git (though I'm no git pro) is the very flexible work-flow options (we use multiple, and they're awesome), the excellent merge algorithm, and the directory/branch structure, to name a few.

Git is great. So it bazaar. It's all this machismo that bugs me. We should really be on the same side trumpeting why dvcs are better.

prog4• 16 years ago

I have to agree.

IMO bzr, git and hg are comparable and these dabates are no different emacs vs vim.

My personal preference is bzr but I quite like hg also. I also like git but the only thing that keeps me away from git is the whole fanboy culture around it.

juliusdavies• 16 years ago

X is a windowing system. It makes no sense to compare Git to X.

mrinterweb• 16 years ago

Personally, I am a big fan of Git's staging feature. I think Git takes the right approach here. I Love having the ability to commit only certain things, and yes, (in cases) only certain changes in a file. This allows for very granular commits if you are trying to keep good history/notes in your commit messages. This also allows you to easily commit changes specific to what you are trying to accomplish with the commit. I prefer small commits with comments specific to the changes rather than "well its working, time to commit everything". I'm not saying you can't do this with other dvcs, but I like Git's default workflow for this.

stevelosh2• 16 years ago

Mecurial's MQ extension is basically git's index on steroids.

With a single MQ patch you basically have git's index. You can continually add things to the patch and then finalize it into a commit when ready.

With multiple patches you have multiple indexes which can be pushed and popped, reordered, folded together, finalized into commits, etc.

To be fair, MQ's user interface needs some work. It's far from perfect.

jedbrown2• 16 years ago

Hmm, I would have said that short-term branches with `rebase -i` are MQ on steroids. I always found MQ to be an odd beast, introducing a new set of commands that are far from orthogonal. Now that bookmarks are reasonably well-supported, albeit with somewhat surprising semantics and certain limitations (assuming you are used to git branches), I only use MQ as an analogue for `git stash`.

koenigdavidmj• 16 years ago

And if you don't like it, the Record extension ( http://mercurial.selenic.com/wiki/RecordExtension ) does most of what Git people would want, although it doesn't yet have the ability to split a modification into modifications of smaller granularity.

dlsspy5• 16 years ago

I gave a long detailed response to this over on reddit:

http://www.reddit.com/r/programming/comments/biv72/why_git_a...

gojomo• 16 years ago

whygitisbetterthanxIsBetterThanwhy-git-aint-better-than-x:

- more readable font sizes and font-vs-background colors

- better use of whitespace

- supporting graphics

- minimal, tasteful use of color/shading

chmike• 16 years ago

I'm about to adopt DVCS but can't decide between git, hg, bzr or whatever. These flame wars are paralyzing because they look like I have to pick a religion.

s_tec• 16 years ago

DVCS folks like to say that the real enemies are the people still using Subversion, rather than the competing DVCS tools. What they fail to realize is that DVCS fragmentation a big part of the reason people like me continue using Subversion. If there were a clear DVCS winner, I would have switched years ago.

Fortunately, it looks like git is starting to take the lead in this fight. As a result, I've started moving some of my projects over. From what I've seen, git has the best internals. The absence of explicit deltas in the core database is a particularly brilliant move on git's part. In the long run, I hope that wins out over bzr and hg's slightly better user experience. After all, it's much easier to fix user interface problems than to change a tool's core architecture.

Why Git Ain’t Better Than X

Related Stories