Re: [RFC/PATCH 1/3] apply: Allow blank context lines to match beyond EOF
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 17, 2010, 08:14 UTC
- Message-ID
- <7vbpfo5le0.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <4B7B94A8.5000102@gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
Show 18 quoted lines
> "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.
Show 14 quoted lines
> @@ -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?