Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

Re: [PATCH] git-svn: handle leading/trailing whitespace from svnsync revprops

From: Eric Wong <hidden>
Date: 2016-06-15 22:44:04

Junio C Hamano [off-list ref] wrote:
Eric Wong [off-list ref] writes:
quoted
diff --git a/git-svn.perl b/git-svn.perl
index 3308fe1..f40ad2c 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1758,10 +1758,16 @@ sub svnsync {
 	# see if we have it in our config, first:
 	eval {
 		my $section = "svn-remote.$self->{repo_id}";
-		$svnsync = {
-		  url => tmp_config('--get', "$section.svnsync-url"),
-		  uuid => tmp_config('--get', "$section.svnsync-uuid"),
-		}
+
+	        my $url = tmp_config('--get', "$section.svnsync-url");
+		($url) = ($url =~ m{^([a-z\+]+://\S+)$}) or
+	           die "doesn't look right - svn:sync-from-url is '$url'\n";
When I checked tmp_config(), I thought that it was returning the
first element (taking the output of "config --get" as a
LF-terminated list) when called in list context, so this would
give the correct sync-url after stripping the trailing LF for
Dennis's case.  The first assignment looks fine, but the second
one looks very funny.

Is it only me who finds that

	($var) = ($var =~ m{^(any regexp)$}) or die "message"

is extremely a roundabout and hard-to-read way to say:

	if ($var !~ m{^(the same regexp)$} {
        	die "message";
	}

which is much easier to read?
The statements are not equivalent, however.  I'd have to add

	$var = $1;

too, because I needed to extract what was inside the ( ) since the '$'
doesn't catch the trailing newline, either.  I also couldn't find any of
the /sm, /m, /s switches useful for making '$' not accept the trailing
newline, either.

I also consider the "or die " part of the line to be uninteresting,
and would rather not waste extra space on it.
I said the first one looks fine, but actually I really _hate_
Perl subs that use wantarray and return one element in scalar
context, and return a list in list context.

This forces the programmer who calls the sub to read the code of
the sub and know that it uses this unusual calling convention.
It forbids them to rely on their common-sense acquired from
experience while coding in Perl, that most functions do not do
that, and a usual sub that is capable of returning a list in a
list context you can find out the number of elemenets, the first
element, and the first few elements by using:

	sub returns_list {
        	my @a = qw(a b c);
                return @a;
	}

	my $number_of_elems = returns_list();
	my ($first_element) = returns_list();
	my ($first, $second) = returns_list();

IOW, writing

	sub returns_funny {
        	my @a = qw(a b c);
                return wantarray ? @a : $a[0];
	}

may make you feel as if you have become a power-coder, and might
even give you a false sense that some parts of your code can
become simpler thanks to that, because you can now write:

	my $first_element = returns_list();

i.e. you did not have to type WHOLE TWO LETTERS ( and )!

But in the longer run, when you want/need other people to help
maintaining such a code, you create unnecessary burden on them.
Good points, I've been mindlessly taking "interesting" things from other
Perl code I've seen over the years and using it in my own without
thinking about it too hard :x

I'll avoid them in the future.  Unfortunately, Git.pm also suffers from
this as well.

-- 
Eric Wong
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help