Slashes in hg branch names #75
Conversation
Based on felipec/git@a160978, with thanks to Felipe Contreras.
git's fast-export doesn't seem to like slashes in branch names
("error: there are still refs under 'refs/hg/origin/branches/<name>").
Work around this by replacing slashes with _SLASH_.
Generalise the *_to_*_spaces() functions top name_*_to_*() functions,
using the mapping NAMES_HG_TO_GIT.
Add a test for this failure mode.
|
Though Travis doesn't seem to be running it.... |
|
I think the travis issue might be because I cherry-picked the relative filenames commit. I'm pretty confident git should not be choking just because slashes exist in the ref name. It's legal to have slashes in branch names in normal git usage. If this really is breaking fast-import, then the bug is almost certainly in git, and working around it with substitution is not the correct fix. Does the test fail if you use completely different branch names with slashes (ie feature/one and task/two)? My intuition is that this will succeed, and the bug we are seeing with pypy is not because the slashes exist, but because they share a common prefix. I am hopeful that this can be fixed without replacing the slashes in branch names. My guess is that this happens because gitifyhg makes the false assumption that branches contain only one slash somewhere, and a split('/') or something similar is inadvertently discarding the remainder of the branch name, so it gets confused with an existing ref. I may be completely off base here; did your research discover otherwise? |
|
Jed (in #62) points out that this is due to a limitation in git: there cannot be both |
|
In order to fix this (and other related problems such as #78), I think we need to introduce a system for mapping branch names between hg and git. Some problems (e.g., clash between |
Fixes #80. This is a controversial fix in some ways; an earlier commit explicitly turned on cloning of closed branches. However, I feel that the default should be to not clone closed branches. There are a few reasons for this. The main one is that a closed branch in mercurial is generally considered the equivalent of a deleted branch in git. Therefore, we do not want the deleted branch in git. A second one is that cloning closed branches can take a great deal of time that is, for the above reason, completely wasted. A third one is that we have a few problems with branch naming (eg #78, #75, #62) that are caused by conflicting branched names. This fix does not solve those issues, but when the conflicting branches are closed branches, it does prevent them from causing a clone to fail outright.
The second part of issue #62.
Filing separate pull request so Travis can process and bless the patch.