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.
Sorting a list of tuples is much more expensive than sorting a list of strings.
For a mapfile with 1.5 million entries, this speeds up save_map from 6 seconds
to 3.5.
In Mercurial, every commit has at least one parent -- root commits have the
null revision as their parent. In Git, root commits don't have any parents.
This difference needs to be papered over in hg-git for 'hg incoming' to work in
Mercurial 3.4+.
Note that this doesn't fix all the broken tests in default -- I haven't had
time to investigate the others.
Since cce24e8019c8 in Mercurial, _walkexplicit returns a tuple, so ensure
we are up to date and take the normalized path which is the first part of the
tuple.
Based on a patch by David Soria Parra <davidsp@fb.com>.
While this has been done since the beginning of time, there's no apparent
justification for it. If an imported commit works out to the same hash as an
existing one, it simply won't be added to the revlog.
The tests all continue to pass. There's already test coverage for reimporting
commits in test-pull-after-strip.t. Also, gimport has worked this way all this
while.
This seems to be a holdover from the days when we used to fetch the entire pack
from the Git server in listkeys. We don't do that any more, so this is also
unnecessary.
Consider a Mercurial commit with hash 'h1'. Originally, if the only Mercurial
field stored is the branch info (which is stored in the commit message rather
than as an extra field), we'd store the rename source explicitly as a Git extra
field -- let's call the original exported hash 'g1'.
In Git, some operations throw all extra fields away. (One such example is a
rebase.) If such an operation happens, we'll be left with a frankencommit with
the branch info but without the rename source. Let's call this hash 'g2'. For a
setup where Git is the source of truth, let's say that this 'g2' frankencommit
is what gets pushed to the server.
When 'g2' is subsequently imported into Mercurial, we'd look at the fact that
it contains a Mercurial field in the commit message and believe that it was a
legacy commit from the olden days when all info was stored in the commit
message. In that case, in an attempt to preserve the hash, we wouldn't store
any extra rename source info, resulting in 'h1'. Then, when the commit is
re-exported to Git, we'd add the rename source again and produce 'g1' -- and
thus break bidirectionality.
Prevent this situation by not storing the rename source if we're adding branch
info to the commit message. Then for 'h1' we export as 'g2' directly and never
produce 'g1'.
What happens if we not only need to store branch info but also other extra
info, like renames? For 'h1' we'd produce 'g1', then it'd be rewritten on the
Git side to 'g2' throwing away all that extra information. 'g2' being
subsequently imported into Mercurial would produce a new hash, say 'h2'. That's
fine because the commit did get rewritten in Git. We unfortunately wouldn't
perform rename detection thinking that the commit is from Mercurial and had no
renames recorded there, but when the commit is re-exported to Git we'd export
it to 'g2' again. This at least preserves bidirectionality.
Deleting a .gitignore using 'rm' results in 'hg add' or 'hg status' aborting.
For example if the top-level .gitignore is removed:
> abort: No such file or directory: .gitignore
This change avoids that by checking the presence of the .gitignore files.
See comment inline for explanation. Also add tests for this (the bug was masked
with rename detection disabled -- it only appeared with rename detection
enabled).
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.
