[PATCH] apply: squash consecutive slashes with p_value > 0

[PATCH] apply: squash consecutive slashes with p_value > 0

[Robie Basak]

"patch" works with -p1 and diffs in the following form:
    --- foo.orig//bar
    +++ foo//bar
    ...

patch(1) says that "A sequence of one or more adjacent slashes is
counted as a single slash."

This patch amends git-apply's filename parsing to behave in the same
way, eliminating both '/'s with -p1 in this example.

Test case included.

Signed-off-by: Robie Basak <robie.basak@canonical.com>
---
 builtin/apply.c              |    8 ++++++--
 t/t4153-apply-doubleslash.sh |   29 +++++++++++++++++++++++++++++
 2 files changed, 35 insertions(+), 2 deletions(-)
 create mode 100755 t/t4153-apply-doubleslash.sh

diff --git a/builtin/apply.c b/builtin/apply.c
index 84a8a0b..78e25fa 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -627,9 +627,13 @@ static char *find_name_common(const char *line, char *def, int p_value,
 			if (name_terminate(start, line-start, c, terminate))
 				break;
 		}
-		line++;
-		if (c == '/' && !--p_value)
+		if (c == '/' && !--p_value) {
+			while (*line == '/')
+			    line++;
 			start = line;
+		} else {
+			line++;
+		}
 	}
 	if (!start)
 		return squash_slash(def);
diff --git a/t/t4153-apply-doubleslash.sh b/t/t4153-apply-doubleslash.sh
new file mode 100755
index 0000000..1ea76b5
--- /dev/null
+++ b/t/t4153-apply-doubleslash.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+#
+# Copyright (c) 2011 Canonical Ltd.
+#
+
+test_description='git apply filenames with double slashes
+
+Try to apply a patch with git-apply where the filename specified has a double
+slash after the first (to-be-stripped) component'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+	test_commit 1 f &&
+	cat > good.patch <<EOF
+diff -u a//f b//f
+--- a//f
++++ b//f
+@@ -1 +1 @@
+-1
++2
+EOF
+'
+
+test_expect_success 'apply diff with double slashes in filenames' '
+	git apply good.patch 2>err
+'
+
+test_done
-- 
1.7.5.4

Re: [PATCH] apply: squash consecutive slashes with p_value > 0

[Junio C Hamano]

Robie Basak <robie.basak@canonical.com> writes:

> "patch" works with -p1 and diffs in the following form:
>     --- foo.orig//bar
>     +++ foo//bar
>     ...
>
> patch(1) says that "A sequence of one or more adjacent slashes is
> counted as a single slash."

It merely says patch(1) treats duplicate slashes that way; it does not
mean it is a useful thing to do in the real life.

Could you justify why such a change is a good thing in your proposed
commit log message?

>  builtin/apply.c              |    8 ++++++--
>  t/t4153-apply-doubleslash.sh |   29 +++++++++++++++++++++++++++++
>  2 files changed, 35 insertions(+), 2 deletions(-)
>  create mode 100755 t/t4153-apply-doubleslash.sh

Can we avoid wasting a new test number for just a single trivial test by
findign appropriate places in existing tests to add new ones to? I think
4133 may be one of the good places (not just checkint between a/f vs b/f,
you would check a//f vs b/f and somesuch).

> diff --git a/builtin/apply.c b/builtin/apply.c
> index 84a8a0b..78e25fa 100644
> --- a/builtin/apply.c
> +++ b/builtin/apply.c
> @@ -627,9 +627,13 @@ static char *find_name_common(const char *line, char *def, int p_value,
>  			if (name_terminate(start, line-start, c, terminate))
>  				break;
>  		}
> -		line++;
> -		if (c == '/' && !--p_value)
> +		if (c == '/' && !--p_value) {
> +			while (*line == '/')
> +			    line++;
>  			start = line;

I am not sure if this is sufficient or necessarily correct.

You are de-dupling slashes only when p_value hits 0. When working on an
input "a///b//c" with -p3, your loop strips one slash per decrement of
p_value between "a" and "b" and then you notice slashes after "b" are
duplicated and clean them up, which would mean you normalized the input to
"a///b/c", not "a/b/c", no?

Re: [PATCH] apply: squash consecutive slashes with p_value > 0

[Robie Basak]

On Thu, Nov 17, 2011 at 09:43:02AM -0800, Junio C Hamano wrote:
> I didn't mention this, but I suspect the code with your patch would not
> touch redundant slashes after it finds "start", either.

What is happening to me is that b//foo with -p1 gets split at the first
slash and then git apply cannot find /foo when it should be looking for
foo. But in the case of b/foo//bar and -p1, without squashing extra
slashes it would look for foo//bar which I presume that it would still
be able to find.

So in my case, I only need duplicate slashes around the -p boundary
point to be removed. I assumed that the squash_slash() later on would
eliminate the rest, but I didn't look into this; if it does it'd be a
different issue to the one that I'm seeing.

I'm now confused about what it will do (which is why I need to look at
it again to make sure), but if it turns out to be easier to just handle
that one boundary point, would you accept a patch that eliminates just
that duplicate, on the basis that in Unix-land duplicate slashes are
perfectly acceptable to be left lying around?

Thanks,

Robie

Re: [PATCH] apply: squash consecutive slashes with p_value > 0

[Junio C Hamano]

Robie Basak <robie.basak@canonical.com> writes:

> I'm now confused about what it will do (which is why I need to look at
> it again to make sure), but if it turns out to be easier to just handle
> that one boundary point, would you accept a patch that eliminates just
> that duplicate, on the basis that in Unix-land duplicate slashes are
> perfectly acceptable to be left lying around?

If that is the case, I would rather say we should even shoot for
simpler. Just tell the patch generator not to include unneeded double
slashes.

Re: [PATCH] apply: squash consecutive slashes with p_value > 0

[Robie Basak]

On Thu, Nov 17, 2011 at 10:07:27AM -0800, Junio C Hamano wrote:
> If that is the case, I would rather say we should even shoot for
> simpler. Just tell the patch generator not to include unneeded double
> slashes.

I don't have a choice about the patch generator. These are humans typing
"diff -ur foo.orig/ foo/" which I think is reasonable.

IMHO, this is a bug in git-apply's -p behaviour. It's not so much about
stripping double slashes; more about doing the -p split in the middle of
the doubled slashes rather than the end. patch does the right thing.