Reece Dunn wrote:
The core plumbing in git is solid. The porcelain, with the 1.5 series,
makes git simpler to use from the command line. Now, the GUI available
for git is seriously lacking.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html