Re: Git User's Survey 2007 unfinished summary continued

[Steven Grimm <koreth@midwinter.com>]

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