This changeset adds test coverage for comparing "hg outgoing -B" in normal
Mercurial usage with Hg-Git usage. This didn't match, since previously, gitrepo
didn't provide a meaningful listkeys implementation. Now, it does.
gitrepo now has access to a GitHandler when a localrepo is available. This
handler is used to access the information needed to implement listkeys for
namespaces (currently, only bookmarks) and bookmarks.
A couple of other tests were testing "divergent bookmark" scenarios. These
tests have been updated to filter out the divergent bookmark output, as it isn't
consistent across the supported Mercurial versions.
In the logic that was attempting to handle the case where the local repo doesn't
have any bookmarks, the assumption was being made that tip resolved to a
non-null revision. In the case of a totally empty local repo, however, that
isn't a valid assumption, and resulted in attempting to set the master ref
to None, which broke dulwich.
The "fix", which avoids the traceback and allows the push to complete (though
still do nothing, since in this case there aren't any changes to push), is to
not tweak the refs at all if tip is nullid. Leaving the special capabilities
ref and not adding a master ref appears to be fine in this case.
The output for "hg push" when there were no changes didn't quite match between
Mercurial with and without Hg-Git, so I changed the behavior to bring it into
synch. The existing "creating and sending data" message was changed to be
included if --verbose is specified.
There was a bug introduced in fa5f235be2cd such that calling hg outgoing on
a Git repository would result in all refs being deleted from the remote
repository (with the possible exception of the currently checked out branch).
It wasn't noticed before because the existing test for outgoing didn't actually
verify the refs on the remote. This changeset fixes the bug, as well as adding
test coverage to allow verifying that the fix works.
When exporting Git commits, verify that the tree and parents objects
exist in the repository before allowing the commit to be exported. If a
tree or parent commit is missing, then the repository is not valid and
the export should not be allowed.
While working on some other tests, I noticed that the push command was returning
exit code 1 on success. This changeset makes hgrepo.push use the same return
code contract as localrepo.push, which makes the exit codes behave as expected.
that mimic a branchname to be maintained on the git side without
a particular suffix - e.g. if the hg repo had a branch "release_05",
and a bookmark created onto it "release_05_bookmark", the branch on the
git side would be named "release_05". When pulling branches back from
git, if an hg named branch of that name exists, the suffix is appended
back onto the name before creating a bookmark on the hg side.
This is strictly so that a git repo can be generated that has the
same "branch names" as an older hg repo that has named branches, and
has had bookmarks added in to mirror the branch names.
This is given the restrictions that
A. hg named branches can never be renamed and B. hg-git only supports
hg bookmarks, not branches
Signed-off-by: Ehsan Akhgari <ehsan.akhgari@gmail.com>
---
I found a number of bugs when I was trying to convert Mozila's hg repository
to git using hg-git. This patch fixes a number of bugs with irregular
author lines present in hg repositories. Git cannot correctly process a
commit object which has a committer or author line in a format that it does
not understand, which makes it not be able to handle the repositories
with have such commit objects.
The added test cases shows the irregular cases that this patch is able to
deal with.
