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.
