login
Search
Reece Dunn wrote:I'm not sure I agree with that. Here's the section on git from the "Comparison with other systems" part of the Mercurial book. I'll reproduce it in its entirety here and add my own comments about each paragraph. > Git is a distributed revision control tool that was developed for managing the > Linux kernel source tree. Like Mercurial, its early design was somewhat influenced > by Monotone. No argument there. > Git has an overwhelming command set, with version 1.5.0 providing 139 > individual commands. It has a reputation for being difficult to learn. It does not have > a user manual, only documentation for individual commands. The part about the user manual is bunk (and was bunk in version 1.5.0, IIRC, so I'm not sure where he gets that.) But the first part of that is the key here. I admit that's even bitten me from time to time. I couldn't remember the name of the "git-instaweb" command just yesterday; doing "ls /usr/local/bin/git-*" was, I'd have to agree, pretty overwhelming. We could probably solve that by tucking the plumbing commands away in a lib or libexec directory and only exposing the porcelain commands in the directory the end user is likely to look at. But that's just an aspect of a more general fact: it's hard to use git without getting exposed to the plumbing at least a little. Another example is the manpages: try to look up the commonly-used options to "git diff" (porcelain) and you will be forced to learn about "git rev-parse" (plumbing). The point is, though, that this is a valid complaint about git's UI that has nothing to do with GUIs. > In terms of performance, git is extremely fast. There are several common cases > in which it is faster than Mercurial, at least on Linux. However, its performance > on (and general support for) Windows is, at the time of writing, far behind that of > Mercurial. A fair statement, though of course that's been improving by leaps and bounds of late and hopefully will soon be an outdated argument. The Windows user experience has been subpar historically. > While a Mercurial repository needs no maintenance, a Git repository requires frequent > manual “repacks” of its metadata. Without these, performance degrades, while space > usage grows rapidly. A server that contains many Git repositories that are not rigorously > and frequently repacked will become heavily disk-bound during backups, and there > have been instances of daily backups taking far longer than 24 hours as a result. > A freshly packed Git repository is slightly smaller than a Mercurial repository, but an > unpacked repository is several orders of magnitude larger. This was true at the time the hg book was written. Now that we have the auto-packing code, hopefully it will be a moot point. So that's one "fix the UI" complaint that has been addressed; whether *successfully* or not, time will tell. But hg definitely had a user experience advantage here until very recently. > The core of Git is written in C. Many Git commands are implemented as shell or Perl > scripts, and the quality of these scripts varies widely. I have encountered a number of > instances where scripts charged along blindly in the presence of errors that should have > been fatal. No doubt this is true as well. Obviously the C-ification process will take care of a lot of this, though of course one can charge along blindly in the presence of errors in any language (including, shock of shocks given the implication here, Python.) To the extent we can find places where this is still true, obviously they should be fixed. I wonder if anyone knows the author of the book well enough to ferret some specifics out of him toward that end. Now, about hg vs. git in general. I actually spent some time this weekend coming up to speed on hg basics just to see what all the UI fuss was about. As far as I can see it is about a wash all told; some things are easier in git and some in hg. However, here's my speculation about why people might claim hg is easier. I see three things: Multiple branches per repo. Mercurial allows them, but you won't find them mentioned anywhere in any of the beginner tutorials. They encourage people to use a "one repo per branch" model. Having gotten used to git's branching model, you'd have to pry that feature out of my cold, dead fingers, but it's fundamentally much easier to understand a model of "if you want to make two unrelated changes to your code, just make two copies of the source tree." It's possible git's introductory documentation should delay talking about "git branch" until later, and start off talking about how to work with one (checked out) branch per repo. Update to a dirty working copy. I think there's a tendency in these parts to vastly underestimate the importance of being able to pull down updates from a master repository while you're in the middle of development. Mercurial's equivalent to bare "git pull", namely "hg pull" followed by "hg update", works fine if you have edits in your working copy; if there are conflicting changes, it pops you into a conflict resolution UI (or adds conflict markers, depending on your settings) and you continue on your merry way after resolving everything. This workflow is really common, especially in corporate settings where there's very fine-grained collaboration going on during initial development (a huge difference from the open-source world where most of the time it's just one person doing an initial prototype.) Right now working this way is a pain in git. Less so now that we have "git stash", but it could still be much, much smoother. Verbosity. IMO Mercurial swings too far in this direction, but in general it's either completely silent or very terse in its output. There is never, as far as I can see, any low-level diagnostic information spit out to the user unless an hg command is run with a "verbose" option. Here's "hg pull; hg update", for example (and "pull" is one of hg's chattier commands): pulling from ../child1 searching for changes adding changesets adding manifests adding file changes added 8 changesets with 8 changes to 3 files (+1 heads) (run 'hg heads' to see heads, 'hg merge' to merge) 3 files updated, 0 files merged, 0 files removed, 0 files unresolved Compare with the equivalent "git pull" and put yourself in the shoes of a user who is running that command for the first time: remote: Generating pack... remote: Counting objects: 9 remote: Done counting 1118 objects. Result has 832 objects. remote: Deltifying 822 objects... remote: 100% (822/822) done Indexing 832 objects... remote: Total 832 (delta 668), reused 0 (delta 0) 100% (832/832) done Resolving 668 deltas... 100% (668/668) done 258 objects were added to complete this thin pack. * refs/remotes/origin/session-fix: fast forward to branch 'session-fix' of ssh://devrs005/~/www old..new: 3de27db..a3d44c1 Already up-to-date. So anyway, there are a few specifics. That's based on just a bit of playing around with hg; maybe the differences go deeper than this, but I think there isn't a huge usability gap between the two systems any more. -Steve - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
