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.
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.
> 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"...
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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
[+] [-] cookiecaper|16 years ago|reply
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|reply
[+] [-] stevelosh|16 years ago|reply
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"...
[+] [-] mrinterweb|16 years ago|reply
[+] [-] stevelosh|16 years ago|reply
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.
[+] [-] micampe|16 years ago|reply
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|reply
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|reply
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.
[+] [-] durin42|16 years ago|reply
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.
[+] [-] jobenjo|16 years ago|reply
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|16 years ago|reply
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|16 years ago|reply
[+] [-] dlsspy|16 years ago|reply
http://www.reddit.com/r/programming/comments/biv72/why_git_a...
[+] [-] loup-vaillant|16 years ago|reply
[+] [-] durin42|16 years ago|reply
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.
[+] [-] chmike|16 years ago|reply
[+] [-] s_tec|16 years ago|reply
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|16 years ago|reply
[+] [-] prog|16 years ago|reply
When did you use it? On what history size? bzr 2.x series is quite fast.
[+] [-] juliusdavies|16 years ago|reply
[+] [-] gojomo|16 years ago|reply
- more readable font sizes and font-vs-background colors
- better use of whitespace
- supporting graphics
- minimal, tasteful use of color/shading