We avoid using dulwich's refs method because it is incredibly slow. On a repo
with a few hundred branches and a few thousand tags, dulwich took about 200ms
to load everything.
This patch only traveses the remote ref directory and cuts that time down to
about 50ms.
It is unclear to me why we keep a file (which can become out of sync) of remote
refs instead of just using dulwich. This caught a missing remote ref in the
test suite.
Originally, I copied the logic for the file scheme which calls
_peerlookup(path) but in mercurial/hg.py they have:
try:
return thing(path)
except TypeError:
return thing
So, our http(s) scheme broke default Mercurial because I tried returning
thing(path) instead of just thing. A test has been added to catch this.
By testing the uri early, we can reuse logic later in the method to parse the
git uri. We rely on the isgitsshuri heuristic to return True or False, and if
True, prepend 'git+ssh://' to the uri.
Arguably, this is fragile, and am open to better ideas, but can't think of
anything else currently.
This add the ability to copy & paste from github's (and other git-style) urls.
Due to how we need to handle this, we need to also ensure that paths that end
with .git are stripped of their extension.
Previously, there was an edge case for Git repositories that started as
Mercurial repositories and had used subrepos where a deleted .hgsubstate would
be ignored and therefore reintroduced.
This patch fixes that behavior by checking for the deleted .hgsubstate file
first.
A test has been added to verify behavior.
If the importer encountered an error half way through a large import, all the
commits are saved, but the mapfile is not written, so the process starts over
from the beginning when run again.
This adds the option for a config value that will save the map file every X
commits. I thought about just hard coding this to 100 or something, but doing it
this way seems a little less invasive.
The default dulwich graph walker only walks from refs/heads. During the
discovery phase of fetching this causes it to redownload commits that are only
referenced by refs/remotes. In a normal hggit case, this seems to mean it
redownloads the entire git repo on every hg pull.
Added a --debug to a test to check the object count (it decreased from 21 to 10
as part of this patch).
Otherwise ImportError wouldn't be raised thanks to demandimport.
Perhaps tests passed at 4b0ecb5952a6 because we are likely to have ignore.pyc
in our mercurial tree.
Upstream mercurial has dropped the ignore module and replaced it with 'include:'
patterns. Let's do the same in hggit.
Ran tests against Mercurial latest (61a01892dd10) and Mercurial 3.4.
filectx.renamed() returns a 2-tuple or None. memfilectx.__init__ expects
the copied argument to be either None or a string. Before, we were
passing a 2-tuple, leading to the memfilectx storing the wrong type.
This eventually resulted in doing a key lookup against a manifest
with a 2-tuple, which made manifest.c throw an error.
Note that one test still fails with 3.4 -- however, it is a bug in core
Mercurial, only affects edge cases (broken symlinks) in the test, and is fixed
in upstream stable.
The old logic was broken -- it didn't work at the boundary between hg and git
commits. The logic in overlayrevlog.parents handles that correctly.
This is the last fix required for Mercurial 3.4.
There really is no point to this -- the sorting is expensive to compute and
the structure is never actually used.
For a mapfile with 1.5 million entries, this speeds up save_map from 3.6
seconds to 0.87.
This is probably the limit of the speedups we can get with pure-Python code.
Any further speedups will have to be made by rewriting these bits in C.
