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>
Since space doesn't conform to GIT branches name standards,
it should be replaced or with another character.
Signed-off-by: Felipe Zimmerle <felipe.zimmerle@indt.org.br>
Signed-off-by: Rocco Rutte <pdmef@gmx.net>
* fixes:
hg-fast-import.py: Sanitize ref names
hg-fast-export.py: Don't attempt to dump revs beyond tip with -m
hg-fast-export.py: Minor tweaks/cleanup
At least the opensolaris hg repo has tag names containing '*',
so sanitize all branch and tag names roughly according to the
specs for git-check-ref-format(1).
Signed-off-by: Rocco Rutte <pdmef@gmx.net>
Merges were completely broken as they ended up with twice the same
parent in git. Still everything besides gitk seemed to work.
This because of 1) the incorrect assumption that a commit's parent is
the commit exported right before it and 2) some confusion with markes
being saved/loaded/used since git-fast-import doesn't allow for a ":0"
mark to map hg revision 1:1 to marks.
The merge "algorithm" now works like this:
1) If the commit's higher parent (highest hg rev), is not the last
commit exported for a particular branch, we issue a "from" command to
place it on top of it.
2) If the commit's lower parent exists, we issue a "merge" for it.
This is much simpler and seems to produce correct merges in git. And
while I'm at it, make output less confusing by prepending the target
branch name to each line.
The "twice the same parent" bug was discovered by Michele Ballabio on
the git list.
Signed-off-by: Rocco Rutte <pdmef@gmx.net>
By default, the key is not changed. This will allow us for fixing up the
off-by-one issue with marks restored using load_cache().
Signed-off-by: Rocco Rutte <pdmef@gmx.net>
