Andreas Ericsson wrote: > On a side-note, git has made my life easier, so I childishly want to > defend it and see it on top of every list in the world. Something I'm > sure I share with more people on this list and with some of the bazaar > users/devs. ;-) Let's then us review what started this thread, namely comparison chart between source control systems http://bazaar-vcs.org/RcsComparisons 1. Decentralized. O.K. 2. Disconnected Ops. O.K. 3. Simple Namespace. Should be named "Simple Rev Names" instead, Bazaar should have note that revnos work only for specific workflows (star-topology); for Git it should be perhaps "Somewhat" here, as <ref>~<n> (or <ref>@{<n>} if reflog is enabled) _are_ simple (if volatile for branch <refs>). $(git-merge-base <ref1> <ref2>), usually "hidden" in <ref1>..<ref2> or <ref1>...<ref2> shortcut is also I think simple. There was huge discussion here about revnos, revids, workflows (development topology), fast-forwards, empty merges etc. Bazaar-NG and Git puts emphasisis on other things. Additionally tags supports removes some of perceived revnos advantages; tags are simple. 4. Supports Renames. I could agree with "Somewhat" because of not yet implemented --follow option to git-rev-list (and therefore all porcelain). Perhaps it would be closer to truth to leave the marker (background color) as for "Somewhat" and write "N/A" with note that Git has contents and pathname based heuristic detection of renames, or just put "Detect" or "Detection" here. I would certainly change description of what means that SCM doesn't "Support Renames" or has it implemented partially. Current explanation relies heavily on _implementation_. The correct wording of current definition would be that SCM doesn't support renames if history of a file "as visible to SCM" is broken into before rename and after rename part, and that SCM support it partially if you can track history of renamed file from post-rename name but there is left in void history of pre-rename file. But with this definition Git _does_ "Supports Renames". I'd rather split "Supports Renames" into engine part (does SCM remember/detect that rename took place _as_ rename, not remember/detect it as copiying+deletion; something other than rename) and user interface part: can user easily deal with renames (this includes merging and viewing file history). 5 and 6. Needs Repository/Supports Repository. The name is very, very unclean and stems from branch-centricness of Bazaar. Git should probably have "Yes" here, as for Git branch is just reference to its tip in revisions DAG (plus optionally branch tip history in reflog). On the other hand Git _can_ share object database like branches can be gathered together to share data into repository. You can have one-branch repositories, you can clone whole repositories (perhaps Bazaar should have "Somewhat" for Supports Repository as it doesn't support cloning of whole repository... bzt, wrong, there is example plugin for that), and you can clone (using Cogito) only one branch of repository and you can fetch only selected branches of repository. Thinking more about it those items should probably read "Support Individual Branches" (as: can you get only the branch you are interested in, can SCM support one-branch workflow) and "Support Branch Grouping" or "Support Data Sharing" (as: can you share DAG between branches, can you share DAG between repositories). 7. Checkouts (as a noun). This probably read "Support Centralized and Disconnected Centralized Workflow" but that is perhaps too wordy. Git would have "No" for "Centralized" and "Somewhat" for "Disconnected Centralized" meaning that you can set up Git repository to be equivalent of heavyweight checkout, and push changes to some given repository on commit. 8. Partial Checkouts (as a verb). Here Git should have perhaps "Minimal", as you can have partial checkouts but only with care (and you still need whole repository). "No?" is also correct (?). 9. Atomic Commits. O.K. You have to remember that there are consequences of having Atomic Commits on the details of Partial Checkouts. 10. Cheap Branching Anywhere. Git should probably have "Yes! Yes! Yes!" here ;-) 11. Smart Merge. O.K. Should probably be explained what constitutes smart merging. Perhaps instead of "Yes" there should be name of default/smartest merge strategy used? 12. Cherrypicks. What constitutes "Yes" here? Why "Somewhat" for Git? It does have git-cherry-pick command for cherry picking... 13. Plugins. I would put "Somewhat" here, or "Scriptable" in the "Somewhat" or "?" background color for Git. And add note that it is easy to script up porcelanish command, and to add another merge strategy. There also was example plugin infrastructure for Cogito, so I'd opt for "Someahwt" marking. 14. Has Special Server. O.K. 15. Req. Dedicated Server. O.K. 16. Good Windows support. I'd put "Cygwin" instead of "No" for Git, although with the same marking. And perhaps add note that Git relies heavily on POSIX. 17 and 18. Fast Local Performance and Fast Network Performance. O.K. 19. Ease of Use. Hmmm... I don't know for Git. I personally find it very easy to use, but I have not much experiences with other SCM. I wonder why Bazaar has "No" there... Too much rewriting to correct the page... -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html