Eric Wong <normalperson <at> yhbt.net> writes: > martin f krafft <madduck <at> madduck.net> wrote: > > also sprach Eric Wong <normalperson <at> yhbt.net> [2007.07.16.0530 +0200]: > > > The major issue with this is that it doesn't handle odd cases > > > where a refname is sanitized into something (say "1234~2" > > > sanitizes to "1234=2"), and then another branch is created named > > > "1234=2". > > > > Well, we can't please everyone, can we? :) > > > > I like Jan's proposal about using the % escape, even though it > > doesn't make pretty branch names. > > I like it, too. How about something like the two functions below? This > will break things a bit for people currently using % in refnames, > however. > > I think this will work rather nicely once I've figured out how the path > globbing code works[1] and where to sanitize/desanitize the refnames > properly. > > It would be far easier to take your approach and sanitize them only > for the command-line, but storing unsanitized git refnames into the > .git/config is something I want to avoid: > > Somebody naming directories on the SVN side with the path component > ":refs/remotes" in them could screw things up for us. Why not "simply" allow some form of escaping in refs, such that special characters CAN be used anywhere. Then git-svn would just have to escape these characters. Something like: git update-ref "refs/remotes/tags/sometag\~1" $sha1 I'm pretty sure that could help fix a lot of other similar issues. Mike - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html