Björn Gustavsson <bgustavsson@xxxxxxxxx> writes: > "git apply --whitespace=fix" will not always succeed when used > on a series of patches in the following circumstances: > > * One patch adds a blank line at the end of a file. (Since > --whitespace=fix is used, the blank line will *not* be added.) > > * The next patch adds non-blanks lines after the blank line > introduced in the first patch. That patch will not apply > because the blank line that is expected to be found at end > of the file is no longer there. > > Fix this problem by allowing a blank context line at the beginning > of a hunk to match if parts of it falls beyond end of the file > (i.e. at least one context line must match an existing line in > the file). > > TODO: We should probably require that at least one *non-blank* > context line should fall within the boundaries of the file. I think that is very sensible; I thought about this after I wrote the review message in the previous round but failed to mention it. Happy to see that you are thinking along the same line. > @@ -2002,11 +2071,17 @@ static int find_pos(struct image *img, > unsigned long backwards, forwards, try; > int backwards_lno, forwards_lno, try_lno; > > - if (preimage->nr > img->nr) > - return -1; > + /* > + * There used to be a quick reject here in case preimage > + * had more lines than img. We must let match_fragment() > + * handle that case because a hunk is now allowed to > + * extend beyond the end of img when --whitespace=fix > + * has been given (and core.whitespace.blanks-at-eof is > + * enabled). > + */ Is it worth to keep the quick-reject if we are not running under blank-at-eof mode? -- 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