
Why Git Ain’t Better Than X - skorks
http://unspecified.wordpress.com/2010/03/26/why-git-aint-better-than-x/
======
cookiecaper
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.

~~~
stevelosh
> 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"...

~~~
ableal
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...](http://doc.bazaar.canonical.com/migration/en/why-switch-to-
bazaar.html)

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]

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

~~~
stevelosh
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.

~~~
koenigdavidmj
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.

~~~
nsm
try crecord ( <http://mercurial.selenic.com/wiki/CrecordExtension> ) for
granularity

------
micampe
> 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
> _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
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.

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

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

~~~
prog
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.

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

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

[http://www.reddit.com/r/programming/comments/biv72/why_git_a...](http://www.reddit.com/r/programming/comments/biv72/why_git_aint_better_than_x/c0mzr6a)

------
loup-vaillant
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.)

~~~
durin42
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
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.

~~~
loup-vaillant
"`darcs` isn't good for all purposes"

I dont understand. What Darcs isn't for that Git _is_ for? And for what usage
specifically Darcs is better? I like Darcs, mind you. I like it better than
Git. However, I don't have enough experience with either to really make an
informed choice, let alone a choice depending on intended usage.

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

------
pieter
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'.

~~~
prog
> 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.

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

~~~
prog
What was the version of bzr and git? Was this windows or unix? I suspect its
unix only. It would be good to see the numbers on both platforms. Is this a
limited rev history or the entire history? You also don't mentioned the exact
commands you run. Do you use n=0 or n=1 with bzr? I would normally use n=1 as
n=1 is not of much interest. Such limited microbenchmarks merely spread FUD.

Also, while choosing a DVCS, the common operations have to be fast not all
operations. So the interesting benchmark would provide numbers for all the
common operation. Just running one operation can be misleading. I do much more
with my DVCS than just run the log operation :-)

Also, I don't see myself doing a log of a full 20+ year history multiple times
during the day (In fact I have never done that). The commands I use normally,
are fast enough large repos with bzr (emacs included).

~~~
dlsspy
You know, I had bzr 1.17 or similar. I upgraded to 2.1 and got the same time
(slightly over 25 seconds). git version is 1.7.0.3. Both on my mac (I don't do
Windows). In both cases, it was whatever "<cmd> clone <url>" does by default.
So pretty much, all defaults all around.

I mentioned this because someone else was saying it was as fast. I don't know
anything about the n= things... I just ran "bzr log > /dev/null" and "git log
> /dev/null" (my shell automatically times all commands).

I tend to use and search logs a lot in my projects. With 2s to generate a log
output, you won't think about the cost of looking through the whole thing for
something (I did similar in an active hg project earlier today).

I do get your point. It's not a... holistic benchmark. In another thread,
someone called fowl on the article discussing size vs. bytes transferred. I
thought it'd be better to think of that as time. Cloning roughly the same
content via bzr and git (memcached master branch -- which is cloned at lp and
contains just about the same history, though is somehow smaller at lp) takes a
bit over 20 seconds and a bit under 4 seconds respectively.

I suppose it's valid to argue that you don't clone much, either. At some
point, one would wonder whether you avoid certain things _because_ they're
slow.

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

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

