Colin Guthrie <gmane@xxxxxxxxxxxxxx> writes:
> 'Twas brillig, and Junio C Hamano at 04/03/11 21:33 did gyre and gimble:
>> In short, Linus and I both know what you are talking about, and we may
>> revisit that issue later, but the thing is that it would not be very
>> pleasant, and not something that can be done in one sitting during a
>> single discussion thread on the list.
>
> As a simple option to avoid that, how about just printing out (by
> default) the line offsets if hunks don't apply 100% cleanly? This would
> at least alert you to the fact that some fixups were needed.
>
> Just a thought...
... 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.
builtin/apply.c | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 14951da..4d22d16 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -2638,6 +2643,14 @@ 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 (offset < 0)
+ offset = 0 - offset;
+ fprintf(stderr, "Applied at %d (offset %d line(s)).\n",
+ applied_pos + 1, offset);
+ }
+
/*
* Warn if it was necessary to reduce the number
* of context lines.
--
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