On Sat, 25 Mar 2006, Davide Libenzi wrote:
>
> I also have to teach libxdiff patch algo to recognize the tag and do the
> right thing during the patch operation.
Btw, git-apply does it, and it's actually quite simple: the code to handle
the "\ No newline" case is literally just this:
/*
* "plen" is how much of the line we should use for
* the actual patch data. Normally we just remove the
* first character on the line, but if the line is
* followed by "\ No newline", then we also remove the
* last one (which is the newline, of course).
*/
plen = len-1;
if (len < size && patch[len] == '\\')
plen--;
if we just remove the last '\n' on a line, if the _next_ line starts with
a '\\' (so the git-apply code actually depends on knowing that the patch
text is dense, and that it's also padded out so that you can look one byte
past the end of the diff and it won't be a '\\').
I don't know how well that fits into xpatch (I never looked at the patch
side, since I already had my own ;), but my point being that handling this
special case _can_ be very simple if the data structures are just set up
for it.
It's also important to realize that (a) you can't actually check the "No
newline" string, because that depends on your locale and (b) it's not
necessarily at the _end_ of the patch, because you can have a patch that
looks like
- next-to-last-line
- last-line
\ No newline at end of file
+ new-end-of-file
+ new-last-line
\ No newline at end of file
ie the first "\ No newline" is in the middle, because it relates to the
last removed line (while the second one obviously relates to the last
added one).
The xdiff patch I sent out automatically does that when generating these
things, of course.
Linus
-
: 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