Get your tools checked; both hg and git (command line) import these
trees in about a second. Consider the command-line versions of the tools
in preference to the GUI wrappers.
You’re running into a case at which git excels and hg is less
efficient. Mercurial uses a separate file as the revlog of each file,
while git likes to keep things more unified. In particular, copying the
same directory twelve times takes virtually no extra space in git. But
how often does that happen? I hope not very. If you routinely import
thousands of files and images, and not just as the initial commit,
a DVCS may not be the right tool for you. Something like rsync or a
centralized VCS would be better — a DVCS is generally tuned for a
single project that holds text files and receives patches and merges
over time. Other kinds of tools make different tradeoffs.
There’s really not much point importing large directory trees
and carefully examining the files that appear; you can read the
documentation if you like. The main lesson here is that git keeps
a snapshot of the entire directory structure, which allows it to
efficiently pack things (the bundle for wordpress is 2.7MB, which is no
larger than the tarball), but it can be more expensive to compute diffs.
Mercurial maintains a lot more per-file information like logs and diffs,
which means that accessing the log of just one file is much faster than
in git, but lots of identical files and directories can have a higher
space cost.
I can create a pathological case, too. Here’s one where git wins:
for dir in {1..100}; do
mkdir $dir
for file in {1..100}; do
touch $dir/$file
done
done
hg add {1..100}; hg commit -m tweedledee
git add {1..100}; git commit -m tweedledum
Yep, that’s 10,000 empty files across 100 identical directories. Git
imports the entire thing in a tenth of a second, and the commit itself
is less than a kilobyte. Mercurial, which creates a logfile for each
file, takes about four seconds to commit the entire thing, and ends up
with 10140 new files in .hg, totalling 40MB.
Here’s one where mercurial wins:
mkdir -p a/b/c/d/e
for i in {1..1000}; do
echo hello >> a/b/c/d/e/file
hg add a; hg commit -m "Commit $i"
git add a; git commit -m "Commit $i"
done
That’s one thousand commits, each introducing a tiny change in
a deeply nested file. Each commit in git introduces eight new
objects, which are individually deflated but stored as separate
files. Eventually, git decides to repack, which takes time. Unpacked,
the whole thing is about 32MB, and packed it’s 620K. Mercurial, on the
other hand, simply appends a few notes to a few logfiles each time, and
the .hg is 396K at the end.
What’s the point of all this? The point is that none of the cases
discussed in this thread are realistic. In everyday usage, with
realistic repositories, both tools are great. Just learn one.
The manuals themselves don’t exactly show you from beginning to end how a commit is constructed, but Git Internals in Pro Git, Internals in the Mercurial wiki, and Mercurial Internals from PyCon 2010 should get you started.