hg-{fast-export,reset}.sh: add git --exec-path to PATH

Starting with Git 2.10.0, the git-sh-setup script expects
the git --exec-path directory to be in the PATH or it will
fail.  Although there is a patch in the works to correct
this, many of the other scripts in the --exec-path directory
also assume the same thing.

Explicitly add git --exec-path to the front of the PATH just
like Git normally does so that git-sh-setup starts working
again without need of the patch and to future-proof the code
against similar breakage in the future.

As a result also switch to just plain ". git-sh-setup" to match
how the rest of the scripts in --exec-path run the setup script.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>

hg-fast-export.sh: prune notes on missing marks

If --hg-hash is given and any marks were found to be missing (i.e. gc'd),
prune the refs/notes/hg tree if it exists.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>

hg-fast-export.sh: handle gc'd marks

If there are any "unnamed" heads in the source repository, those
revisions will be imported successfully but not attached to any
ref and the next time gc is run they will be removed.

When git fast-import attempts to read the --import-marks file it
will complain (and die) when it gets to the mark that refers to the
now-deleted revision.

Avoid this issue by removing any no-longer-existing marks from the
input marks file.

This is never an issue for a full import, only for an incremental
import.

This change is only a partial solution for incremental imports.  It
works fine as long as no future import attempts to use the gc'd
"unnamed" head as a parent or something to be tagged.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>

hg-fast-export.py: include unnamed head's branch

"Unnamed head" is a bit of a misnomer, these "heads" actually do
have a branch name.

Show it to help diagnose the issue.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>

hg-fast-export.sh: let git manage the marks

Ever since Git 1.5.1, "git fast-import" has supported an "--import-marks"
command and allowed the same file name to be used without conflict for both
the "--import-marks" and "--export-marks" options.

Therefore get rid of the kludgey code that exports to a temp file and then
attempts to combine the old and the new with uniq etc. etc.

By allowing Git to handle this the code is much simpler, Git always knows
about all the marks and there's no concern about the input to the 'uniq'
command not being in sorted order.

However, do export the marks to a different file so that in the unlikely
event of a disk full error where "git fast-import" fails to write the new
"--export-marks" file, no marks are lost and on success just replace the
old marks file with the new one.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>

hg-fast-export.sh: replace awkward git-branch usage with git-for-each-ref

The porcelain "git-branch" command is not intended to necessarily be
machine readable.  Switch to the "git-for-each-ref" plumbing command
instead which streamlines the process of creating hg2git-heads.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>

hg-fast-export: get rid of ridiculous 'devnull@localhost' default

Use 'unknown' for an unknown email address by default rather than
the ridiculous 'devnull@localhost' value.

If compatibility with the previous default is needed than an explicit
-U devnull@localhost option must be given.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>

hg-fast-export.py: do not mangle UTF-8 characters

Set the proper values so that UTF-8 characters in the source
repository are exported without mangling them to '?' characters.

With this change, the current value of LANG and LC_XXX environment
variables have absolutely NO effect on the fast-export result
which is how it should be.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>

hg2git.py: do not require python 2.7

The subprocess.check_output call is a version 2.7 or later only
thingy.  Replace it with something that's more compatible but still
avoids using os.popen.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>

hg-fast-export.py: don't step on previous --hg-hash notes

If exporting in incremental mode it's important to preserve
any preexisting refs/notes/hg value which is easily accomplished
by adding a reset + from combination.

Ideally the previous refs/notes/hg value should be stored in the
heads cache and warned about changes outside the import process
just like all the other heads, but that's something for another time.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>

Switch from os.popen() to subprocess.check_output() for running git rev-parse

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.

Remove obsolete and unsupported SVN tools

Hat tip to Sebastian Pipping for giving me a nudge to remove them.

Use backquotes

Use GitHub markdown

Rename README to README.md

Survive corrupt source repositories

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.

hg-{fast-export,reset}.sh: always set ROOT to full path

The dirname utility by itself may return a relative path,
combine it with cd and pwd -P to get an absolute one instead
in a fully POSIX compliant fashion.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>

Merge branch 'master' into girocco

Conflicts:
hg-fast-export.py
hg-fast-export.sh

Only dump heads in head cache

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.

Update README with note about no working directory

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.

Annotate commits with the hg hash as git notes in the hg namespace

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.

hg-fast-export.sh: minor clean up and code optimization

hg-fast-export: add support for --flatten option

When Git initially creates a ref, it stores a file in the file
system with the same name as the ref.  If the ref contains '/'
characters, then the created file will have a path involving more
than one directory.

Unfortunately this means that Git cannot simultaneously create,
for example, a ref named 'refs/heads/master' and one named
'refs/heads/master/default'.  This would require 'master' to be
both a file and a directory.

On the other hand, hg tags do not have this restriction.

Add a new --flatten option that converts '/' characters to '_'
characters in ref names so that directory/file ref name conflicts
can be avoided.  For example, given a 'master' and 'master/default'
tag, they would generate 'refs/heads/master' and
'refs/heads/master_default' ref names when --flatten is used
thereby avoiding the conflict.

The --flatten option may be required in order to successfully
convert hg source repositories containing these conflicts.

hg-fast-export.py: do not generate invalid ref names

Git has various rules about what is and is not a valid ref
name.  These are summarized in the 'git help check-ref-format'
output.

Update the ref name conversion code to take into account all the
rules.  Also compile the regexs only once and eliminate invalid
index exceptions.

These reference names no longer cause exceptions:

  /a
  a//b

These reference names no longer generate invalid names:

  a@{b}
  a.lock

All ref names that were previously converted to valid Git ref names
should continue to be converted to the same ref name now.

hg-fast-export: add support for -U <addr> option

Instead of always using 'devnull@localhost' as the email address
when it is unknown, allow the address to use when the email is unknown
to be specified by the new -U <addr> option.

The default if -U <addr> is not used remains 'devnull@localhost'.

The specified address may be surrounded by optional whitespace and/or
optional '<' and '>'.  The only thing that will cause it to be rejected
is if it's empty (after stripping surrounding "crud" characters and
removing internal '<', '>' and "\n" characters).

hg2git.py: do not generate invalid fast-export names or emails

Git processes the user name and email portion of an author name by
first stripping any "crud" characters from both the beginning and
end of each, then removing any remaining '<', '>' or "\n" characters
and finally adding a surrounding '<' and '>' to the email and joining
that to the user name with a space.

While Git may appear to allow an empty name and/or email address in
the raw author data, doing so ultimately causes problems when any
attempt is made to use rebase, filter-branch or other such utilities,
so empty name and/or email addresses also need to be avoided.

The source commit data from hg appears to have few restrictions on
the format of the author information.  This can easily result in bogus
author data being produced in the fast-export stream that then causes
git fast-import to fail with an error.

Fix this by performing Git-like processing of both the user name and
email as extracted from the hg commit author information.

The basic idea is to take anything to the left of the first '<' and
to the right of the last '>' as the user name and anything between
the first '<' and the last '>' as the user email.  If there is no
'<' then the author data is either treated as a name only (if there's
no '@') or an email address only (if it contains an '@').

If there is no name, the part of the email up to the first '@' is used.

The resulting name and email are processed in the same manner as Git
before emitting them into the fast-export output stream.

The same output should be produced as the previous version produced
when that output is something that is valid for a fast-export stream.
Input that would have previously produced invalid fast-export author
data now produces valid output instead.

Some examples that now produce valid output instead of invalid:

  first middle last <fml <at> example.com>
  name <at> loca.tion
  <name>
  <name
  name>

hg-fast-export.sh/hg-reset.sh: replace egrep with grep

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.

hg-fast-export.py: do not sort merge commit parents

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.

Merge pull request #23 from ritcheyer/master

checking for - and converting - backslashes

Thank you for your contribution!

hg-fast-export.py: improve authors file compatibility

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.

hg-fast-export.sh: clean up help text and support --help

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."

hg-fast-export: support new --hgtags option

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.

hg-fast-export.py: do not lose file mode changes

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.

hg-fast-export.py: support older hg versions

Do not use the closesbranch function as it was added in later
versions of hg.  Use its definition instead.

hg-fast-export.py: restore compatibility with older python

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.

hg-fast-export.sh: Do not ignore hg-fast-export.py exit code

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.

Revert "Don't ignore hg-fast-export.py exit code"

This reverts commit 9643aa5df2e14e01867bc4266958b8c8081c3377.

Revert "Make bashism conditional on the shell being bash"

This reverts commit aaccfba9a0cfcfdd4db1e629b50d65b1c479b64f.

checking for - and converting - backslashes

Merge pull request #22 from TracyWebTech/master

Not using branchtags

Fixing for hg 2.9

Fix typo+grammo in README

Make bashism conditional on the shell being bash

This avoids breakage due to 9643aa5d on shells other than bash.

Give a proper error message when the hg repo is not known

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.

Merge pull request #16 from zr40/patch-1

Don't ignore hg-fast-export.py exit code

Don't ignore hg-fast-export.py exit code

Fix mapping option, close #10

Update README with pointer to the github issue tracker

Rename hg-fast-export.txt to README

Merge pull request #7 from living180/master

Make Windows support actually work

Make hg-fast-export (actually) work on Windows

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.

Merge pull request #6 from aried3r/master

Fix for Mercurial 2.3 compatibility

Organized imports

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

Merge pull request #5 from living180/master

Make hg-fast-export work on Windows

Make hg-fast-export work on Windows

* use sys.stdout.write instead of print to avoid end-of-line issues
* use os.devnull instead of hard-coding /dev/null

Merge pull request #4 from aried3r/master

Fixed a bug related to sanitizing branch names.

Applied rule #7 of git-check-ref-format

Rule #7 of git-check-ref-format states "7. They cannot end with a dot
'.'." which was not yet implemented in fast-export. This commit fixes
this.

Update documentation: The tool is no longer called hg-fast-import

Mention the author map file in the readme

Add usage info for the --force option

Commits with no parent need a reset command.

This fixes a problem where a repository is imported incorrectly when there is a merge
between two branches with no common history.

Support the case where the author field has an empty email address, i.e. it is of the form 'name <>'.

Use hg methods to extract name and email when doing user fixup

hg-fast-export.sh should fail if git-fast-import fails

Previously, git-fast-import could fail, and exit with a non-zero status.
But the exit status of hg-fast-export.sh would not reflect this.

Support passing --force to git-fast-import

Remove \" from the user string before trying to extract name and email

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 "verifying branch" message is not very interesting

Particularly if the repo has hundreds of branches.

Simplify handling of parents of exported commit

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.

Maintain backwards compatibility for ui setup

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

Update to work with mercurial ui refactorings

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

hg-fast-export: Compare HG revisions when merging

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.

hg-fast-export: Support branches without parents

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-fast-export: Point out that only local repos are supported

Signed-off-by: Frej Drejhammar <frej.drejhammar@gmail.com>

hg-fast-export: Update todo now that tag movement is supported

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

Merge branch 'from-jmcmullan' into develop

Conflicts:
hg-fast-export.py

hg-fast-export: add option to track remote branches under a custom namespace

Add -o, --origin <name> to allow user to set a namespace used
when importing remote branches.

Signed-off-by: Fabrizio Chiarello <ponch@autistici.org>

hg export: Support tag movement

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.

hg2git: Update copyrights and maintainership information.

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

hg-fast-export: Make default branch customizable

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>

hg-fast-export: Catch up with mercurial crew API changes

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

hg-fast-export.py: Use appropriate file mode for symlinks.

hg-fast-export: work still if git-commands are not in PATH

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>

Revert "hg2git: Replaces space with "_" in branches name"

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 cdfdae36c8a73fb257eceff33b03d2f320bafc6b.

hg-fast-export.py: sanitize tildes (~) in branch names

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>

Clarify where 'HEAD' branch name comes from

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

hg2git: Replaces space with "_" in branches name

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>

hg-fast-export.py: Cache possibly sanitized branch names

...instead of doing it for every single commit.

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

Merge branch 'fixes'

* 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

hg-fast-import.py: Sanitize ref names

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>

hg-fast-export.py: Don't attempt to dump revs beyond tip with -m

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

hg-fast-export.py: Minor tweaks/cleanup

Remove some unused variables, generalize dictionary-splitting and make
sure we don't sort filename lists twice (repo.status returns files
sorted already).

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

Fix shell substitution typo

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

hg-reset.py: Use mangle_key() for load_cache() as hg-fast-export.py does

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

hg-fast-export.py: Rewrite merge logic

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>

hg2git.py: Allow consumers to modify keys of dicts returned by load_cache()

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>

hg2git.py: Use git-rev-parse to get SHA1s instead of reading files below refs/ directly

This should now also properly support packed refs.

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

hg2git.py: Map 'HEAD', 'default' and '' hg branches to 'master' in git

Also add a note where HEAD is comming from.

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

Allow for $PYTHON environment variable specifying python binary to use

Signed-off-by: Rocco Rutte <pdmef@gmx.net>

This prevents invalid command errors caused by bytes not being flushed to
git-fastimport in the same order as they were written to the buffer.

Signed-off-by: Scott Lamb <slamb@slamb.org>

Removed git-p4 from fast-export. It has been moved to git.git:contrib/fast-import.

Signed-off-by: Simon Hausmann <shausman@trolltech.com>