This adds some test coverage for cases that are not buggy. There is a bug
lurking here, and an upcoming patch will extend these tests to cover those
cases too.
A user recently got confused and managed to track and export a .git
directory, which confuses git and causes it to emit very odd
errors. For example, cloning one such repository (which has a symlink
for .git) produces this output from git:
Cloning into 'git'...
done.
error: Updating '.git' would lose untracked files in it
and another (which has a .git directory checked in) produces this:
Cloning into 'git'...
done.
error: Invalid path '.git/hooks/post-update'
If it ended there, that'd be fine, but this led to a line of
investigation that ended with CVE-2014-9390, so now git will block
checking these revisions out, so we should try to prevent
foot-shooting on our end. Since some servers (notably github) are
blocking trees that contain these entries, default to refusing to
export any path component that looks like it folds to .git. Since some
histories probably contain this already, we offer an escape hatch via
the config option git.blockdotgit that allows users to resume
foot-shooting behavior.
See inline comments for why the additional metadata needs to be stored.
This literally breaks all the hashes because of the additional metadata. The
changing of hashes is unfortunate but necessary to preserve bidirectionality.
While this could be broken up into multiple commits, there was no way to do
that while preserving bidirectionality. Following the principle that every
intermediate commit must result in a correct state, I decided to combine the
commits.
We use Dulwich's rename detector to detect any renames over the specified
similarity threshold.
This isn't fully bidirectional yet -- when the commit is exported to Git
the hashes will no longer be the same. That's why that isn't tested here. In
upcoming patches we'll make sure it's bidirectional and will add the
corresponding tests.
Mercurial rev 1660b80d8083 introduced a transaction manager upstream. This
means that the closetransaction and releasetransaction methods on the pull
operation have gone away.
Git 1.8.0 was released in late 2012. Given that we only support versions of
Mercurial released in 2014, it doesn't make sense to support versions of Git
this old.
hg-git translates octopus merges into a series of merges, called an octopus
explosion. The intermediate octopus explosion commits are not recorded in
the mapfile -- only the final commit is. This means that they show up in the
export list and have to then be detected and filtered out.
Don't initialize the incremental exporter with octopus explosion commits.
Previously, if there were octopus merges early in the history, we'd initialize
the incremental exporter with the first one's parent, then calculate the diff
of that against the first commit we actually cared about exporting. That's slow
and wasteful.
For a particular real-world repo with one octopus merge 1/3 of the way in
history, this is a 10x improvement for 'hg gexport' with one commit to export
-- 60 seconds to 6.
This prepares for an upcoming patch.
In theory, we could pass the context into export_hg_commit, but there's some
encoding shenanigans going on there that I don't want to delve into.
fd926a0f2592 in upstream Mercurial added a matches function to the manifest.
This broke 'hg incoming -p' with hg-git. This patch adds a simple implementation
that fixes the problem.
This was caught by the tests, and now the tests pass.
This is quite similar to syntax Git supports. In the future maybe core
Mercurial could be extended to support this, but I think this independently
makes sense in hg-git.
This actually has no direct impact here, but it allows extensions to customize
the list of filtered refs and be sure of the order in which they'll be
processed.
This also means we get to clean up a lot of the code around here. It isn't
really feasible to break this up into several commits because the assumptions
in the old calling code are too closely tied to the old local_heads() way of
doing things.
This is a replacement for local_heads and code duplication around it.
Centralizing all this logic also makes it much easier for extensions to define
other sorts of refs.
