Re: [BUG] git-am silently applying patches incorrectly

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

 



Colin Guthrie <gmane@xxxxxxxxxxxxxx> writes:

> 'Twas brillig, and Junio C Hamano at 04/03/11 22:42 did gyre and gimble:
>> ... and a patch to do so would look like this.  "git apply -v" and (GNU)
>> "patch -p1" seems to report exactly the same numbers for the problematic
>> patch and the initial state that started this discussion.
>> ... 
>
> Personally I wouldn't bother making offset absolute... (equiv of
> abs(offset)) as knowing it applied earlier or later could be useful...
> the direction is lost here and I don't really see why that's nicer for
> the user. But maybe that's just my opinion?

I don't have a strong opinion on this either way; I would just imitate
what GNU patch would do, which would probably be to show the offset as-is,
except that it flips the sign if it is being run in reverse with -R
option.

A bigger question I would actually care _more_ about is if this should be
on by default without -v.  We usually do not allow fuzz by default for
safety, and we do warn loudly when -C reduces the context and we actually
need to use it to match the preimage.

In any case, here is an update to match what GNU patch seems to do more
closely.

-- >8 --
Subject: [PATCH] apply -v: show offset count when patch did not apply exactly

When the line number the patch intended to touch does not match
the line in the version being patched, GNU patch reports that
it applied the hunk at a different line number, with how big an
offset.

Teach "git apply" to do the same under --verbose option.

Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
---
 builtin/apply.c |   16 ++++++++++++++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/builtin/apply.c b/builtin/apply.c
index 14951da..a231c0c 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -2432,7 +2432,8 @@ static void update_image(struct image *img,
 }
 
 static int apply_one_fragment(struct image *img, struct fragment *frag,
-			      int inaccurate_eof, unsigned ws_rule)
+			      int inaccurate_eof, unsigned ws_rule,
+			      int nth_fragment)
 {
 	int match_beginning, match_end;
 	const char *patch = frag->patch;
@@ -2638,6 +2639,15 @@ static int apply_one_fragment(struct image *img, struct fragment *frag,
 				apply = 0;
 		}
 
+		if (apply_verbosely && applied_pos != pos) {
+			int offset = applied_pos - pos;
+			if (apply_in_reverse)
+				offset = 0 - offset;
+			fprintf(stderr,
+				"Hunk #%d succeeded at %d (offset %d lines).\n",
+				nth_fragment, applied_pos + 1, offset);
+		}
+
 		/*
 		 * Warn if it was necessary to reduce the number
 		 * of context lines.
@@ -2785,12 +2795,14 @@ static int apply_fragments(struct image *img, struct patch *patch)
 	const char *name = patch->old_name ? patch->old_name : patch->new_name;
 	unsigned ws_rule = patch->ws_rule;
 	unsigned inaccurate_eof = patch->inaccurate_eof;
+	int nth = 0;
 
 	if (patch->is_binary)
 		return apply_binary(img, patch);
 
 	while (frag) {
-		if (apply_one_fragment(img, frag, inaccurate_eof, ws_rule)) {
+		nth++;
+		if (apply_one_fragment(img, frag, inaccurate_eof, ws_rule, nth)) {
 			error("patch failed: %s:%ld", name, frag->oldpos);
 			if (!apply_with_reject)
 				return -1;
-- 
1.7.4.1.299.ga459d


--
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]