Having trouble with SVN branches/tags that have `+` character - changes to `%2B`

SubGit
#1

I have already sent this via email and had response, but wanted to post here in case anyone else has similar issue currently. See response from Tmate employee below as well as my further response.

Hi there, I am trying to migrate svn to git - however some of branches and tags in svn have the + character in the name. When subgit translates these branches/tags the + character is translated into %2B - this then causes a knock on effect which causes issues. Is there a way to stop subgit from changing this character? i can see an old issue about this where this was supposedly fixed some years ago, but can’t find anything in the documentation about it - Make the "+" sign to %2B translation behaviour disengageable
Any help much appreciated!

#2

To further clarify why this is an issue, when pushing a branch or tag with %2B in the name, particularly for Gitlab (haven’t tried with another version control source, don’t need to for my case) links with these branch/tag names are broken and give back 404. However having tested the branches on GitLab with just the + character the links work fine.

#3

This was the response via email from Tmate:

Unfortunately current version of SubGit has ref names names encoding hardcoded and there is no way to disable or configure it and the only workaround is to rename SVN branches/tags. Please let me know if you’re still interested in making encoding configurable, we’ll then add it the next version of SubGit.

With best regards,
Alexander Kitaev,

#4

Again although I responded on email, I will respond here:

This is unfortunate… I have rather a large codebase with many repositories, each with many projects in them, and again many branches/tags like this. it would not be feasible or worth the time and effort to rename these branches and tags. It would be great if this could be made configurable in the next version, preferable asap.

Do let me know if you decide to move forward with this and rough timescales for release. Sounds like it should be a quick-ish fix if it’s just changing hardcoded values to be dynamic. Hope to hear back soon!