git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: git discussion list <git@vger.kernel.org>
Subject: Re: [PATCH] translate bad characters in refnames during git-svn fetch
Date: Sun, 15 Jul 2007 20:30:50 -0700	[thread overview]
Message-ID: <20070716033050.GA29521@muzzle> (raw)
In-Reply-To: <20070715130548.GA6144@piper.oerlikon.madduck.net>

martin f krafft <madduck@madduck.net> wrote:
> Hi,
> 
> I am trying to track/convert the Debian pkg-mdadm repository with
> git-svn:
> 
>   svn://svn.debian.org/svn/pkg-mdadm/mdadm/trunk
> 
> My problem is that the fetching fails:
> 
>   fatal: refs/remotes/tags/2.6.1-1~exp.1: cannot lock the ref
>   update-ref -m r311 refs/remotes/tags/2.6.1-1~exp.1
>   c6e351ea25dc90714048e33693099595c2d5dab8: command returned error:
>   128
> 
> This is because the ~ character is an invalid character for
> a refname (it's used to specify the nth parent).
> 
> So I figured that the best way to deal with this is to introduce
> a conversion filter to git-svn, but I cannot figure out where it has
> to go. My perl is rusty and even after an hour now with the code,
> I could not find the right spot.
> 
> The following patch works, but I can't really explain why. Moreover,
> it does not change the STDERR output, so you'll still get stuff like 
> 
>   r340 = 0dc5693471af9dfdb712c1342071ba1040af8963
>   (tags/2.6.1-1~exp.3)
> 
> which makes me think that it's translating the refname too late.
> However, the end result looks sane.
> 
> Comments welcome,

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".

git-svn should at least keep track of what it got sanitized to, to
avoid clobbering branches.

I started working on this a while back but haven't gotten around
to revisiting it:
http://thread.gmane.org/gmane.comp.version-control.git/45651

> ---
> git-check-ref-format(1) documents which characters may be contained in
> a refname. Since Subversion has different rules, an import can result in
> problems, such as:
> 
>   fatal: refs/remotes/tags/2.6.1-1~exp.1: cannot lock the ref
>   update-ref -m r311 refs/remotes/tags/2.6.1-1~exp.1
>   c6e351ea25dc90714048e33693099595c2d5dab8: command returned error: 128
> 
> This patch translates bad characters to valid substitutes to enable imports of
> tags/branches/whatever using characters that git does not allow in refnames.
> 
> Signed-off-by: martin f. krafft <madduck@piper.oerlikon.madduck.net>
> ---
>  git-svn.perl |   24 +++++++++++++++++++++++-
>  1 files changed, 23 insertions(+), 1 deletions(-)
> 
> diff --git a/git-svn.perl b/git-svn.perl
> index 299b40f..de43697 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1239,7 +1239,29 @@ sub new {
>  	$self;
>  }
>  
> -sub refname { "refs/remotes/$_[0]->{ref_id}" }
> +sub refname {
> +	my ($refname) = $_[0]->{ref_id};
> +	## transform the refname as per rules in git-check-ref-format(1):
> +	# no slash-separated omponent can begin with a dot .
> +	# /.* becomes /,*
> +	$refname =~ s|/\.|/,|g;
> +	# It cannot have two consecutive dots .. anywhere
> +	# .. becomes ,,
> +	$refname =~ s|\.\.|,,|g;
> +	# It cannot have ASCII control character space, tilde ~, caret ^,
> +	# colon :, question-mark ?, asterisk *, or open bracket[ anywhere
> +	# <space> becomes _
> +	# ~ becomes =
> +	# ^ becomes @
> +	# : becomes %
> +	# ? becomes $
> +	# * becomes +
> +	# [ becomes (
> +	$refname =~ y| ~^:?*[|_=@%\$+(|;
> +	# It cannot end with a slash /
> +	$refname =~ s|/$||g;
> +	"refs/remotes/$refname";
> +}
>  
>  sub svm_uuid {
>  	my ($self) = @_;
> -- 

-- 
Eric Wong

  reply	other threads:[~2007-07-16  3:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-15 13:05 [PATCH] translate bad characters in refnames during git-svn fetch martin f krafft
2007-07-16  3:30 ` Eric Wong [this message]
2007-07-16 11:15   ` Jan Hudec
2007-07-16 17:47     ` martin f krafft
2007-07-17 12:28       ` Eric Wong
2007-07-17 13:17         ` martin f krafft
2007-07-26 10:59           ` Robert Ewald
2007-07-26 12:35             ` Martin F Krafft
2007-07-28  7:23         ` Mike Hommey
2007-07-28  7:33           ` David Kastrup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070716033050.GA29521@muzzle \
    --to=normalperson@yhbt.net \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).