Re: [PATCH] translate bad characters in refnames during git-svn fetch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux