On Feb 21, 2013, at 12:15 PM, Chow Loong Jin wrote: >I'll admit that git isn't the simplest one, the others are not perfect either. >To this day, I can't for the life of me figure out how to use CVS. Thank >goodness git-cvsimport works.
Of course, CVS is 20+ years old so its ancient model is working against you. >SVN is simple enough, but so is git when used with only linear history. But >let's not forget the horrible hack that is svn tagging/branching. True, but also not much of a mental stretch when you realize it's just creating new directories in the repo. >Bzr is simple enough as well, but $deity help you when you get incompatible >pack format repositories Mostly not an issue any more, since 2a format has been the only sane format to use for a few years now. Yes, you do run into old branch formats now and then. Sigh. >, or when bzr suddenly decides that your branches have diverged for no >apparent reason whatsoever. I agree with this one. It's a real problem with UDD when you have both an upstream branch (e.g. lp:foo) and a packaging branch (e.g. ubuntu:foo). >At least with git, you know when you've rewritten history -- you're no longer >on the same commit. #9 on Steve Bennett's list is right on target IMHO, but I've had this discussion so many times before, I don't have much energy for it again. """ 9. Git history is a bunch of lies The primary output of development work should be source code. Is a well-maintained history really such an important by-product? Most of the arguments for rebase, in particular, rely on aesthetic judgments about “messy merges” in the history, or “unreadable logs”. So rebase encourages you to lie in order to provide other developers with a “clean”, “uncluttered” history. Surely the correct solution is a better log output that can filter out these unwanted merges. """ Cheers, -Barry
signature.asc
Description: PGP signature
