Change <repo> to <local-repo> so that it's clear that we invoke from a local repository;
Add 'git checkout HEAD' command as we need to run it as the final step.
Thanks
From time to time contributors spend time doing work that will not be
accepted as it duplicates functionality that is already provided with
the mapping files. Try to dissuade them from doing that by explaining
the reasons in the comment.
'>&' is apparently a bashism, change '>& /dev/null' to '2>&1 > /dev/null'.
Problem reported by KatolaZ <katolaz@freaknet.org>.
Resolves#99 and closes#100.
Instead of just crashing when the found readlink does not understand
'-f', fall back to the pre ac887f310f
behaviour and print an error message if we fail to find
hg-fast-export.py.
Calling hg-fast-export.sh via a symlink used to fail because the
script would look for hg-fast-export.py in the symlink‘s
directory. This patch adds symlink resolution using greadlink with a
fallback to readlink in order to support MacOS. That way you can
safely add a symlink to hg-fast-export.sh somewhere in you PATH.
Fixes https://github.com/frej/fast-export/issues/93
If a branch name starts with '/' it will be split into ['', ...] and
then mapped over with dot(), only dot() does not handle the empty
string. Teach dot() to handle the empty string.
This fixes the underlying problem in issue #91.
When core.ignoreCase is true, which it is by default on OSX,
fast-import will produce empty changesets for renames that just change
the case of the file name. As this most probably is not the desired
behavior, trigger an error but allow the conversion to proceed if
--force is used.
The change in 6cf9397bd6 broke support for
bare repositories. In a bare repo git rev-parse --show-toplevel would
return an empty string and cwd would then be changed to the user's home
directory. In the home directory git rev-parse --git-dir would either
fail or return an unrelated repo.
Problem reported by Ralf Rösch.
Fast-export has traditionally sourced the internal git-sh-setup from
Git, following the release of Git 2.10 this no longer works. Fast-export
only uses the functionality of git-sh-setup for two things: cd:ing to
the git repo dir and setting up the GIT_REPO environment variable. To
future-proof fast-export start doing what we need by hand in
fast-export.
Acknowledgments to Louis Sautier who reported the problem and tested the
fix.
os.popen() uses the shell, this is dangerous when the branch-name
contains characters which are interpreted by the shell, therefore switch
to subprocess.check_output() which doesn't involve the shell.
This closes issue #66.
As all branches created on the git side are transformed by
sanitize_name(), this should be a safe backwards compatible change. If a
user is doing incremental imports and sanitize_name() now suddenly
modifies the branch name, verify_heads() would already have complained
on the first incremental run.
Thanks goes to Steve Tousignant<s.tousignant@gmail.com> for discovering
the problem.
This is a piece of code which frequently attracts pull requests which
are summarily rejected. As there is no "git blame" for rejected pull
requests, try to avoid misguided work by adding a comment at the
relevant place.
When an import is restarted the first new note commit must use
refs/notes/hg^0 as the parent. As refs/notes/hg is only updated at the
end of a session we cannot have it present in all note commits. Neither
can we generate new marks for note commits as that would require a new
mapping scheme from hg versions numbers to git marks. A new mapping
scheme would break existing incremental import setups.
We therefore restructure the code to do the notes at the end of an
import session, thus only requiring a refs/notes/hg^0 reference in the
first commit.
Branch and tag names can now be renamed using a mechanism similar to the
-A option for author names.
-B specifies a mapping file for branch names, and -T a mapping file for
tags.
Apparently a bug (http://bz.selenic.com/show_bug.cgi?id=3511) in
multiple released versions of Mercurial could produce commits where
files had absolute paths.
As a "healthy" repo should not contain any absolute paths, it should be
safe to always strip a leading '/' from the path and let the conversion
continue.
When a mercurial repository does not use utf-8 for encoding author
strings and commit messages the "-e <encoding>" command line option
can be used to force fast-export to convert incoming meta data from
<encoding> to utf-8.
When "-e <encoding>" is given, we use Python's string
decoding/encoding API to convert meta data on the fly when processing
commits.
If there is a tag with the same name as a tag, "git rev-parse <name>"
can give the hash of the tag instead of the branch. "git rev-parse
refs/heads/<name>" must be used to make sure we only find branches.
If you run the commands listed in usage
```bash
mkdir repo-git # or whatever
cd repo-git
git init
hg-fast-export.sh -r <repo>
```
you are not given a working directory to start working in. I was
caught off-guard by this when I ran `git status` and everything in the
repo was listed as deleted. A quick google search indicates I'm not
the only one who was surprised.
If the --hg-hash argument is given, the converted commits are
annotated with the original hg hash as a git note in the "hg"
namespace.
The notes can be shown by git log using the "--notes=hg" argument.
According to the POSIX standard, egrep is an obsolescent equivalent
of grep -E. In fact, the patterns actually being used with egrep do
not require use of extended regular expressions at all, so a plain
'grep' can be used rather than 'grep -E'.
Replace egrep with grep to improve compatibility across systems.
In a merge commit, the first parent is always the same parent that
would be recorded if the commit were not a merge and the other
parent(s) record the commit(s) being merged in.
Preserving this order is important so that log --first-parent works
properly and also so that the merge history is not distorted by an
incorrect permutation of the DAG.
Remove the code that sorts the merge parents based on node id so
that the correct DAG order is preserved.
The authors file format accepted by git-svnimport and git-cvsimport
actually allows blank lines and comment lines that start with '#'.
Ignore blank lines and lines starting with '#' as the first
non-whitespace character to be compatible with the authors file
format accepted by the referenced tools.
Intercept -h/--help before git-sh-setup so the proper script name
can be shown instead of "hg fast-export.sh" which is wrong.
Reorder the long option descriptions to be in the same order as
the short usage since, as the help says, "argument order matters."
Add support for a new --hgtags option. When given, any .hgtags
files that may be present are exported.
Normally this is not desirable. However, when attempting to mimic
the actions of other hg exporters that always export any .hgtags
files this option can help produce matching export data.
If the file mode changes (for example from 10644 to 10755), but the
actual text of the file itself does not, then the change could be
missed since the hashes would remain the same.
If the hashes match, also compare the gitmode values before deciding
the file is unchanged.
Since hg runs and supports older versions of python, hg-fast-export.py
should too. Replace dictionary comprehension with equivalent code that
supports versions of python older than 2.7.
