Dulwich treats ref names internally as unicode strings (probably
because of Python 3?), which means that at some points it tries to do
os.path.join between the repo path and the unicode of the ref name,
which fails miserably if we construct the repo with a str and not a
unicode. Kludge around this problem.
Fixes issue 172.
This is a roll-forward of 3df4d529a2f2, which should be valid now that
the previous change defends against accidentally writing unicode tags
inside the templater.
If we don't do this we might end up with unicodes being written using
ui, which then breaks in popbuffer in test-encoding.t. This appears to
be an academic concern until we start passing unicode paths to git
repos, which we need to do in order to resolve some other problems. Yay.
bookmarks.write is deprecated and it was showing warning messages in
test-hg-branch.t with the latest test runner from core mercurial. Tested with
both hg 2.8 and hg tip.
Dulwich treats ref names internally as unicode strings (probably
because of Python 3?), which means that at some points it tries to do
os.path.join between the repo path and the unicode of the ref name,
which fails miserably if we construct the repo with a str and not a
unicode. Kludge around this problem.
Fixes issue 172.
Upstream added opargs to exchange.push and uses it as kwargs to the
pushoperation constructor (59da9543ec6c). There was an attempt to fix this in
hggit (2eb4c0de6bc6) but it passes the exchange.push kwargs directly to
pushoperation(), where we actually need to pull out the opargs and pass them as
kwargs.
Previously, cloning from a git ssh uri (e.g. git@github.com:user/repo.git)
would prepend the local file path because Mercurial classifies this as a path
(since there is no scheme at the beginning of the string). This patch fixes
that by doing the same logic as before in hgutil.url so that the correct hgrc
path is written.
The latest version of Mercurial validates that a path contains the .hg
directory. This breaks when pulling/pushing to git repos.
This patch makes a gitrepo a valid path as well.
Refactors the logic that decides if a local directory is a git directory into a
separate function. This will let us use it later on to integrate with
Mercurial's new paths component.
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).
