Originally 9643aa5d did this by using a bashism even though the
/bin/sh interpreter is being used.
Then ea55929e attempted to compensate for this by disabling the
bashism when the interpreter was not actually bash which results
in the hg-fast-export.py exit code still being ignored in that case.
Instead check the error code without requiring a bashism.
hg-fast-export.sh always passes the --repo flag to hg-fast-export.py.
If, for some reason, we have a state file where the repo-url is an
empty string the checks in hg-fast-export.py will not work and the
user will be confused. Therefore we check that the url is specified
before calling hg-fast-export.py.
Because on Windows sys.stdout is initially in text mode, any LF
characters written to it will be transformed to CRLF, which causes git
to blow up. This change uses Windows platform-specific code to change
sys.stdout to binary mode.
After an update to Mercurial 2.3 the module 'repo' was removed and the
program crashed when trying to convert a repository. I checked the
imports with 'pyflakes' and removed all unused ones, repo (among
others) was never used.
http://www.selenic.com/repo/hg/rev/1ac628cd7113#l9.1
Signed-off-by: Frej Drejhammar <frej.drejhammar@gmail.com>
Reported-by: Cole Robinson <crobinso@redhat.com>
Thank's to Cole Robinson for reporting the bug and providing a fix
which was adapted to this patch.
The original bug report:
I was recently converting a few mercurial repositories to git, and
noticed certain commits had their date reset to Jan 1 1970.
An example repo:
http://hg.fedorahosted.org/hg/virt-manager
An example commit:
http://hg.fedorahosted.org/hg/virt-manager/rev/41182500ddef
After some poking, it seems the culprit was that the "author:" was
surrounded by quotation marks
The previous code did an awful lot of work to infer the parents of an
exported commit, incorporating information from many sources. But
there were multiple bugs in this scheme, sometimes resulting in merge
commits with two parents pointing to the same commit object.
Instead, use a much more straightforward process of mapping the
parents stored in hg.
hg-fast-export uses hg's branch order (from the log) when merging,
this is a problem. Consider the case:
HG repo A has revisions 1-10. Repository B is cloned from that.
Subsequently, A adds revision 11, and B adds a different change which
also has revision 11. If B now pulls from A, A's rev11 will have the
number 12; if A then pulls from B, the reverse also holds. So the logs
are different even though they contain the exact same changes.
hg-fast-export will thus create different git repositories for A and B,
even though the contents are identical for all practical purposes.
In particular, the repos would be identical if A and B had used git from
the beginning.
To fix that, compare HG revisions instead of log positions.
Previously we fed the full revision only for the first one and deltas
for all following including branches being forked off. This doesn't work
with branches that are forked from revision 0. In case such a branch is
found, we now also feed the full revision.
Signed-off-by: Rocco Rutte <pdmef@gmx.net>
HG tag movement is now supported with this patch.
This patch creates a .git/hg2git-mapping file, which maps
HG revision numbers to HG hashes. Combined with the
.git/hg2git-marks file, which maps HG revisions to GIT hashes,
we can now reprocess all tags at the end of each hg export
operation.
Add -M, --default-branch <branch_name> to allow user to set
the default branch where to pull into
Signed-off-by: Fabrizio Chiarello <ponch@autistici.org>
In git 1.6.0, most git tools with a dash in the name will no
longer be installed in $bindir. This patch makes hg-fast-export
use the "git <command>" form so it will work even if "git" is
the only piece of git machinery in the user's PATH.
On the other hand, the "git <command>" form does not help for
sourcing a shell script (with "."). So use the full path to
source "git-sh-setup".
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
The get_branch() function's purpose is to detect whether a mercurial
branch name actually should be considered the default branch.
Sanitizing branch and tag names for git is done in sanitize_name().
Noted by Jonathan Nieder.
This reverts commit cdfdae36c8.
In git-check-ref-format (1), there is the following rule for refnames:
3. It cannot have ASCII control character (i.e. bytes
whose values are lower than \040, or \177 DEL), space,
tilde ~, caret ^, colon :, question-mark ?, asterisk *,
or open bracket [ anywhere;
and indeed, this rule is enforced by "git fast-import". hg-fast-export
already checked for all of the visible characters listed except for ~
and converted them to underscores. For some reason the tilde was
forgotten. This patch makes good on the omission.
Note that control characters are still left alone.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Rocco Rutte <pdmef@gmx.net>
