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.
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.
> But I work at a large company where all the source code is in a single repostory.
Sure, Google does this with perforce.
You are correct, that if you desire a single truly massive repository, you will eventually have trouble with git. However:
> It's just not scalable to large organizations.
Of course it is. The solution is to have multiple repositories and then use something on top of git to tie the repositories together as needed. For example, this is how the android project is being managed:
I've heard of this scenario before, but don't understand this situation. What possible technical reason would justify a billion lines of code needing to be in one repository? If it's a matter of history, perhaps we just need a better import tool.
A company with a couple of applications will likely have a dozen or more shared libraries or other resources.
You could create a repository for each resource, but resources are merged and split over time, a change in a resource may require application changes as well, etc.
All in all it is often just simpler to make a nice directory structure and treat it as one repository rather than deal with dozens of repositories.
I have sort of this problem myself, I have 20 or so shared frameworks in my “big repository” where I would like to release a few of them as F/OSS, but I am using Git and it is too much of a hassle for me needing to then put these frameworks in their own repositories.
Git submodules not only are still separate repositories (making merging and splitting the shared resources problematic) they also require maintenance in the repository they are added to, so in practice a symbolic link is much simpler (as you do not need to update that link each time the submodule is updated).
git does have the ability to do partial history clones and partial repository checkouts.
However, you can surely see that the goals of requiring the code to be in a single repository but requiring the ability to only access part of it at a time are conflicting.
There are numerous ways to assemble a product out of lots of subprojects. It would be ridiculous for something like ubuntu to try to put everything into a single repository when all of the common usage patterns have the users working as if they were independent (and often even under different administrative domains).
In Ubuntu it wouldn't make sense because they're taking most of the code from upstream anyway and it changes slowly; I was just using it to give a sense of scale.
The scenario where a single repository becomes handy is when you want to change a method in a shared library fix all the callers in the same commit, and you can do that because the code isn't public and you know all the callers. (It's much the same reason Linux prefers drivers to be in-tree.)
But I'm not sure I entirely want to defend this model; just pointing out that it exists, and the people who like it aren't going to change how the whole company works just to adopt git.
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.
Collecting check-list points ;-). Thank you, this is a very good one. Anyone know off the cuff about Bazaar and Hg ?
(P.S. Are you one of those Perforce users with large amounts of binary data ? Those use cases being ignored is giving me pause about the whole DVCS hoopla, e.g. here http://news.ycombinator.com/item?id=1219082 )
> 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"...
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.
Comments
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.
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.
> But I work at a large company where all the source code is in a single repostory.
Sure, Google does this with perforce.
You are correct, that if you desire a single truly massive repository, you will eventually have trouble with git. However:
> It's just not scalable to large organizations.
Of course it is. The solution is to have multiple repositories and then use something on top of git to tie the repositories together as needed. For example, this is how the android project is being managed:
http://source.android.com/download/using-repo
I've heard of this scenario before, but don't understand this situation. What possible technical reason would justify a billion lines of code needing to be in one repository? If it's a matter of history, perhaps we just need a better import tool.
A company with a couple of applications will likely have a dozen or more shared libraries or other resources.
You could create a repository for each resource, but resources are merged and split over time, a change in a resource may require application changes as well, etc.
All in all it is often just simpler to make a nice directory structure and treat it as one repository rather than deal with dozens of repositories.
I have sort of this problem myself, I have 20 or so shared frameworks in my “big repository” where I would like to release a few of them as F/OSS, but I am using Git and it is too much of a hassle for me needing to then put these frameworks in their own repositories.
Git submodules pretty much solve this problem in many cases.
But not in the case explained.
Git submodules not only are still separate repositories (making merging and splitting the shared resources problematic) they also require maintenance in the repository they are added to, so in practice a symbolic link is much simpler (as you do not need to update that link each time the submodule is updated).
git does have the ability to do partial history clones and partial repository checkouts.
However, you can surely see that the goals of requiring the code to be in a single repository but requiring the ability to only access part of it at a time are conflicting.
There are numerous ways to assemble a product out of lots of subprojects. It would be ridiculous for something like ubuntu to try to put everything into a single repository when all of the common usage patterns have the users working as if they were independent (and often even under different administrative domains).
In Ubuntu it wouldn't make sense because they're taking most of the code from upstream anyway and it changes slowly; I was just using it to give a sense of scale.
The scenario where a single repository becomes handy is when you want to change a method in a shared library fix all the callers in the same commit, and you can do that because the code isn't public and you know all the callers. (It's much the same reason Linux prefers drivers to be in-tree.)
But I'm not sure I entirely want to defend this model; just pointing out that it exists, and the people who like it aren't going to change how the whole company works just to adopt git.
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.
Collecting check-list points ;-). Thank you, this is a very good one. Anyone know off the cuff about Bazaar and Hg ?
(P.S. Are you one of those Perforce users with large amounts of binary data ? Those use cases being ignored is giving me pause about the whole DVCS hoopla, e.g. here http://news.ycombinator.com/item?id=1219082 )
> 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"...
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]
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.