On 8/11/07, Fred B fredb7@gmail.com wrote:
On 8/8/07, Brian Mitchell binary42@gmail.com wrote:
I'm surprised you took that as an attack on mercurial(...)
On 8/11/07, Jacob Rus jacobolus@gmail.com wrote:
Sorry... my post was certainly not intended as an attack on hg, or bzr, or darcs, or any other system.
But really, the day-to-day usage of git is not IMO a serious barrier to its use by "non-power-users". It's just not that hard IMO to do the basic stuff.
I don't think anybody has attacked Mercurial or other systems. It's just that after using a lot of those systems (hg, svk, git, darcs and bzr in a lesser way), Mercurial is my first choice and git the last one. I sincerely wonder why some people seems to favor git recently, because it's a lot less user friendly than other systems, IMHO.
I just wanted to convince everyone to try both (if not more) systems before weighting for one, that's all.
Then please do be more careful. I can easily give examples of where you were quite inaccurate:
- Git is much more difficult to install than Mercurial. Even with
MacPorts: e.g. Git needs new versions of openssh, openssl, curl, rsync, etc. and install more than 135 different commands! This take a lot of time and can be difficult if you have installed some of those outside of MacPorts. On Tiger, the only thing you need before installing Mercurial is upgrading Python to 2.4+. Then it takes 20 sec.
So MacPorts updates some dependencies to ensure one has an up to date environment. The phrase "Git needs new versions" is quite misleading. Git does not require a number of those installations but the package manager you are using has chosen those for you. Over that, both require hefty compilation (Python is not a lightweight package itself either) but it comes down to one easy command in both cases.
- Documentation: Git install a man page for each command (~135) and
have no user manual, not the easiest way to find information when you need it, IMO. Mercurial has 3 man pages and complete doc, check the [official site][1] and the unofficial [hg book][2] (check the comparison between Mercurial and other systems, BTW).
I think you ought to check the git website. There is indeed documentation for each command with good coverage on practically everything git can do but there are also documents on getting started, moving from other systems, setting git up, and even a MANUAL [0]. I find documentation in git a little sub-optimal but having used mercurial in a number of cases I would put the to in similar cases. The reason for so many man pages in git is that it documents and exposes more than just the highest level commands. Git provides a lot of low level stuff that can come in handy when you need it (fortunately rare now that the interface has matured). Fortunately people who want to make use of these commands (maybe for integration into other high-level systems -- textmate?) aren't left in the dark.
- I consider myself a power user and Git is definitely more difficult
to learn and use than Mercurial. The all "index tree" concept adds unneeded complexity, IMHO. (Allan has a hard time making a Git bundle for TM because of that. See the [qit bundle thread][3].) I think that if git is chosen for TM bundles, there will be more git related questions on this list than anything else.
This is one important point but there is more to it than meets the eye.
Indeed, git is not simple to dive into if the frame of reference being used is another version control system. The concepts in git are rather simple and the documentation explains them well. The drawback is that a lot of these concepts are new rather than shared with other systems making it somewhat hard to start off running and expecting to replicate everything done in a different system.
I've found that trying to understand the fundamentals helped me move from the basic commands stage into a much larger range of commands. I can now say that Git's design is rather simple... I just never accepted that answer until I was able to see the complete thing in my mind. Having gone through all of that, I am in the process of helping my coworkers through a migration from Subversion to Git. It will certainly be interesting but so far, they very quickly became capable enough to do everything they did in Subversion.
Measuring learning curves with building a bundle is somewhat unfair as well. Some of the things git does at an integration level are certainly different from those at a basic user level. Again, git has many levels of detail to choose from depending on your needs.
- I read that a Git repository requires frequent manual "repacks" of
its metadata. Mercurial repository needs no maintenance.
Repacking the object database is a simple command and does not need to be done often. The main reason for the command is to optimize the internal representation of objects. Git provides a rather efficient storage system so repacking shouldn't need to be done unless you either need to compress space usage or feel a performance hit after a while. There are possibly ways to automate this but I don't consider it a nuisance since I even bother with this more than once a week if even that. I'm sure people could happily go for months in some cases.
- AFAICT, Mercurial's source code is MUCH more clean and readable (and
I'm not a big fan of Python).
Actually, having been involved in some research into some git pull behavior, I have to say that git is rather nice. I can read C pretty well and don't consider myself allergic to {}'s but pushing syntax aside, there isn't much to complain about.
Some people do get annoyed by the fact that git has a load of shell scripts surrounding the core git command. This is being worked on as a summer of code project IIRC. Though... I guess I don't mind shell scripts either since I come from the unix background in the first place.
I think these sorts of points are far too anecdotal. I consider that there is something valid behind some of them. You will have to try harder to make those points more apparent or at least much more accurate.
Anyway... I hope you see my point. I could lay down my own arguments for Git but I'll say straight out that I'd be completely happy with Mercurial as well. In the long run, anyone interested in version control _should_ learn Git as it really does do some interesting things. Mercurial has some interesting things as well. In fact, even though darcs isn't the most qualified system, it is worth checking out in the name of expanding the mind (I would not recommend the system for textmate's use.. but that is a complicated topic coming from a long time darcs user -- best avoided).
For the people who end up not having their favorite chose, tailor is a wonderful tool (among other options in some cases). I recommend that those who feel their options have been left out regroup and setup something to allow everyone to work in harmony.
Brian.
[0] http://www.kernel.org/pub/software/scm/git/docs/user-manual.html which was linked to from the front page.