From: martin f krafft <hidden> Date: 2016-06-15 22:43:21
also sprach Eric Wong [off-list ref] [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.
On the other hand, we could make the translation regexps
configurable...
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"if they can get you asking the wrong questions,
they don't have to worry about answers."
-- thomas pynchon
From: Eric Wong <hidden> Date: 2016-06-15 22:43:21
martin f krafft [off-list ref] wrote:
also sprach Eric Wong [off-list ref] [2007.07.16.0530 +0200]:
quoted
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.
# transform the refname as per rules in git-check-ref-format(1):
sub sanitize_ref_name {
my ($refname) = @_;
# It cannot end with a slash /, we'll throw up on this because
# SVN can't have directories with a slash in their name, either:
if ($refname =~ m{/$}) {
die "ref: '$refname' ends with a trailing slash, this is ",
"not permitted by git nor Subversion\n";
}
# It cannot have ASCII control character space, tilde ~, caret ^,
# colon :, question-mark ?, asterisk *, or open bracket[ anywhere
#
# Additionally, % must be escaped because it is used for escaping
# and we want our escaped refname to be reversible
$refname =~ s{( \%~\^:\?\*\[\t)}{uc sprintf('%%%02x',ord($1))}eg;
# no slash-separated component can begin with a dot .
# /.* becomes /%2E*
$refname =~ s{/\.}{/%2E}g;
# It cannot have two consecutive dots .. anywhere
# .. becomes %2E%2E
$refname =~ s{\.\.}{%2E%2E}g;
$refname;
}
sub desanitize_ref_name {
my ($refname) = @_;
$refname =~ s{%(?:([0-9A-F]{2})}{chr hex($1)}g;
$refname;
}
On the other hand, we could make the translation regexps
configurable...
Hopefully not needed. I fear it would just add to confusion.
[1] I don't remember writing the globbing code myself, maybe it was my
psychotic alter ego, but I'm having trouble following it at this time of
the night/morning.
--
Eric Wong
From: martin f krafft <hidden> Date: 2016-06-15 22:43:22
also sprach Eric Wong [off-list ref] [2007.07.17.1428 +0200]:
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.
Well, wait. git-svn usually works in its own repo, and if that's
tracked by another repo, then it is tracked under the
remote/whatever namespace, so there should not be any conflicts. You
also hardly ever run git-svn to clone stuff *into* an existing repo,
so there can't be conflicts with existing refnames-with-%. Thus the
only breakage is if a person creates a new refname inside a git-svn
repo, which uses % in such a way as to collide with an imported
branch/tag/whatever from git-svn. That's not breakage, since git
will just refuse to do it.
Remember that we're only translating from <char> -> %XX, never the
other way around, really. Okay, we might be during git-svn
rebase/dcommit, but only for those refnames which we store in
.git/svn/ anyway. So a user-specified refname containing % will not
be a problem, will it?
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.
I am glad you're having the same problem; makes me feel less stupid.
:)
Somebody naming directories on the SVN side with the path component
":refs/remotes" in them could screw things up for us.
Those people should be tarred and feathered. git owns the trademark
on these names.
sub desanitize_ref_name {
my ($refname) = @_;
$refname =~ s{%(?:([0-9A-F]{2})}{chr hex($1)}g;
$refname;
}
We could make it escape to %25; instead of %25. That's ugly but it
would make desanitation a little safer.
quoted
On the other hand, we could make the translation regexps
configurable...
Hopefully not needed. I fear it would just add to confusion.
I was thinking about something like.
git-svn clone ...
...
error: remote branch/tagn name includes ~, which git does not
allow. please specify a replacement character in .git/config
and then have config.svn-remote.svn.translations simply be a list of
pairs in vim pairlist syntax:
~:!,^:#,.:\,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"it is easier to be a lover than a husband for the simple reason
that it is more difficult to be witty every day
than to say pretty things from time to time."
-- honoré de balzac
From: Robert Ewald <hidden> Date: 2016-06-15 22:43:24
Hello,
I am very interested in a functionality like this.
martin f krafft wrote:
quoted
sub desanitize_ref_name {
my ($refname) = @_;
$refname =~ s{%(?:([0-9A-F]{2})}{chr hex($1)}g;
$refname;
}
We could make it escape to %25; instead of %25. That's ugly but it
would make desanitation a little safer.
In my limited knowledge I wonder if that would confuse shell scripts.
quoted
quoted
On the other hand, we could make the translation regexps
configurable...
Hopefully not needed. I fear it would just add to confusion.
I was thinking about something like.
git-svn clone ...
...
error: remote branch/tagn name includes ~, which git does not
allow. please specify a replacement character in .git/config
and then have config.svn-remote.svn.translations simply be a list of
pairs in vim pairlist syntax:
~:!,^:#,.:\,
Having the user specify replacements leads to diversion which would not be
desired. Consider the case where two git users clone a svn repo and later
pull from each other. Different replacements would cause confusion in this
case. That can of course be remedied by having the same replacements but
then configuration is not needed.
Is there anybody working on this feature at the moment? Can I pull from
somewhere? I am hard pressed for that feature but my ability to contribute
is only in testing and reporting bugs.
Greetings
--
Robert Ewald
From: Martin F Krafft <hidden> Date: 2016-06-15 22:43:24
also sprach Robert Ewald [off-list ref] [2007.07.26.1259 +0200]:
Is there anybody working on this feature at the moment? Can I pull
from somewhere? I am hard pressed for that feature but my ability
to contribute is only in testing and reporting bugs.
As I told you on IRC, I am on my way out for holiday but will read
email, so if you need non-urgent feedback, please write. Please
include my name or reply to this thread for me to see it.
--
Martin F. Krafft Artificial Intelligence Laboratory
Ph.D. Student Department of Information Technology
Email: krafft@ailab.ch University of Zurich
Tel: +41.(0)44.63-54323 Andreasstrasse 15, Office 2.18
http://ailab.ch/people/krafft CH-8050 Zurich, Switzerland
Spamtraps: krafft.bogus@ailab.ch krafft.bogus@ifi.unizh.ch
gentoo: the performance placebo.
From: Mike Hommey <hidden> Date: 2016-06-15 22:43:24
Eric Wong <normalperson <at> yhbt.net> writes:
martin f krafft <madduck <at> madduck.net> wrote:
quoted
also sprach Eric Wong <normalperson <at> yhbt.net> [2007.07.16.0530 +0200]:
quoted
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