Git has a well-hidden notion of extra fields. They aren't accessible from the
CLI, but Dulwich can create them. They're a better place to store Mercurial's
extra metadata than the commit message.
An upcoming patch will switch hg-git to saving the metadata in the Git extra
fields. This commit:
(a) prepares for that
(b) extracts other Git extra fields so that commits from Git with such fields
roundtrip correctly
Previously, we'd iterate over the extra elements in arbitrary order. We now
sort the elements and store them in deterministic order.
Without sorting, the included test fails half the time.
Git makes use thin pack transfer optimization, by default.
Some repository hosting services (like a code.google.com) are require thin pack
optimization.
This patch enables dulwich's thin_packs option by default.
Upcoming patches will switch to the new-style command decorator instead of the
explicit command table. That doesn't mesh well with top-level command functions
defined in other modules.
Ubuntu's current LTS release (Trusty Tahr) comes with Mercurial 2.8.2,
which still works fine with current code. The older LTS comes with a
version that's broken, but I don't have to worry about that anymore.
hg pull calls listkeys for bookmarks. This would previously cause a pack with
all refs to be fetched. For Mercurial mirrors of Git repositories where only
some refs were mirrored, this would cause problems in a bunch of ways:
- A larger pack would be fetched than necessary.
- The final refs written out to the Git repo would only be the set of refs we
were actually interested in. If a GC was subsequently run, unreferenced
objects would be deleted. Those objects might be referred to on subsequent
fetches, which could cause hg-git to crash.
We replace all that logic with a simple null fetch. The tests introduced in the
previous patch ensure no regressions.
hg perfrevset 'max(fromgit())' on a repo with around 60,000 commits:
before: ! wall 1.055093 comb 1.050000 user 1.050000 sys 0.000000 (best of 10)
after: ! wall 0.148586 comb 0.140000 user 0.140000 sys 0.000000 (best of 62)
In reality, perfrevset doesn't clear the Git-to-Mercurial map, which means that
a call like `hg log -r 'max(fromgit())'` speeds up from around 1.5 seconds to
0.6.
For a repository with around 60,000 commits, perfrevset for gitnode becomes:
before: ! wall 1.130716 comb 1.130000 user 1.130000 sys 0.000000 (best of 9)
after: ! wall 0.178828 comb 0.180000 user 0.180000 sys 0.000000 (best of 54)
In reality, perfrevset doesn't clear the Git-to-Mercurial map, which means that
a call like `hg log -r 'gitnode(...)'` speeds up from around 1.5 seconds to
0.6.
Mercurial commit a6d634896102 added support for hg cat across subrepositories.
That caused these tests to break. Fix this by using hg manifest instead.
