4 ms·

Inaccurate. For example, in the section for "Any Workflow," the author contends that git is better than bzr, hg, svn, and perforce. However, this is completely

Inaccurate. For example, in the section for "Any Workflow," the author contends that git is better than bzr, hg, svn, and perforce. However, this is completely false. bzr has far better support for the central repository (svn-style workflow) with its linking of repositories and hg and bzr both have excellent support for the models that Git supports. Funny that the site tries to defend against fanboyism while it itself is a poster boy for it.

wmf 18y ago
The "Any Workflow" section is a little confusing. The fine print says "[Other SCMs] can do the simple flows I've described above, but they cannot do them with multiple simultaneous local branches." I don't understand this well enough to be convinced, and it's hardly good form to use examples that don't demonstrate your point.
- schacon 18y ago
  You make a good point, so I have removed the dscm tags from that one. I added this because I feel that the ability to keep full branches in the same repository that you can push and delete easily gives you far greater flexibility than bzr or hg, which you can only get the exact same functionality by having separate repositories that are clones of each other. However, since that's not what I was demonstrating in that section and it's a bit too complicated to amend easily, I've removed it and focused in that section on the advantages over svn and perforce. perhaps later...
  - newt0311 18y ago
    I should point out that hg is perfectly capable of maintaining multiple named branches in the same physical repository. Checkout hg branch. I am not that familiar with bzr but it probably has something similar.
schacon 18y ago
I disagree - I feel that the branch model in Git and its support in the distributed models gives Git an advantage over bzr and hg in overall workflow flexibility, including the centralized model. However, wmf below is correct in that I did not defend that properly, so I have amended that section. Furthermore, I have been using Git since the pre 1.0 days several years ago - way before most people were using it, so 'fanboyism', a term that I hate, is obviously not why I use it or why I try to teach it. I feel that it is a legitimately better choice for most people than these other tools and this is my attempt to make those points as simply and as straightforward as possible. If you feel I am technically incorrect on anything, please email me and I _will_ fix it.

wmf 18y ago

The "Any Workflow" section is a little confusing. The fine print says "[Other SCMs] can do the simple flows I've described above, but they cannot do them with multiple simultaneous local branches." I don't understand this well enough to be convinced, and it's hardly good form to use examples that don't demonstrate your point.

schacon 18y ago
You make a good point, so I have removed the dscm tags from that one. I added this because I feel that the ability to keep full branches in the same repository that you can push and delete easily gives you far greater flexibility than bzr or hg, which you can only get the exact same functionality by having separate repositories that are clones of each other. However, since that's not what I was demonstrating in that section and it's a bit too complicated to amend easily, I've removed it and focused in that section on the advantages over svn and perforce. perhaps later...
- newt0311 18y ago
  I should point out that hg is perfectly capable of maintaining multiple named branches in the same physical repository. Checkout hg branch. I am not that familiar with bzr but it probably has something similar.

schacon 18y ago

I disagree - I feel that the branch model in Git and its support in the distributed models gives Git an advantage over bzr and hg in overall workflow flexibility, including the centralized model. However, wmf below is correct in that I did not defend that properly, so I have amended that section. Furthermore, I have been using Git since the pre 1.0 days several years ago - way before most people were using it, so 'fanboyism', a term that I hate, is obviously not why I use it or why I try to teach it. I feel that it is a legitimately better choice for most people than these other tools and this is my attempt to make those points as simply and as straightforward as possible. If you feel I am technically incorrect on anything, please email me and I _will_ fix it.