* 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>
This isn't used right now in git-p4 but I use it in an external script that loads git-p4 as module.
Signed-off-by: Simon Hausmann <shausman@trolltech.com>
Collect "unknown" source branches separately and register them at the end.
Also added a minor speed up to splitFilesIntoBranches by breaking out of the loop through all branches when it's safe.
Signed-off-by: Simon Hausmann <simon@lst.de>
A perforce command with all the files in the repo is generated to get
all the file content.
Here is a patch to break it into multiple successive perforce command
who uses 4K of parameter max, and collect the output for later.
It works, but not for big depos, because the whole perforce depo
content is stored in memory in P4Sync.run(), and it looks like mine is
bigger than 2 Gigs, so I had to kill the process.
[Simon: I added the bit about using SC_ARG_MAX, as suggested by Han-Wen]
Signed-off-by: Benjamin Sergeant <bsergean@gmail.com>
Signed-off-by: Simon Hausmann <simon@lst.de>
When using git-p4 in this manner:
git-p4 clone //depot/path/project myproject
If "myproject" already exists as a dir, but not a valid git repo, it fails
to create the directory.
Signed-off-by: Kevin Green <Kevin.Green@morganstanley.com>
Need to use min instead of max for prev/cur to avoid out-of-bounds
string access. Also treat "i" as index of the last match instead of
a length because in case of a complete match of the two strings
i was off by one.
