Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > "rocketscienc01100101 ." <rocketscienc01100101@xxxxxxxxx> writes: > >> http://i.imgur.com/BoJSjm9.png >> >> Here's a screenshot that shows the problem. > > (better cut-and-paste the text than sending a PNG image) > >> There's always a misplaced line in the output (most of the time >> a[href^=tel] { }), no matter where in the file the changes are. > > The part after the @@ are ignored by patch tools. They are here just for > convenience. They are a guess of what the patch hunk belongs to. For > C/Java/Ada/... programs, it's the function name. Git does not know about > CSS syntax, so it guesses wrong (last line starting with a letter I > guess, not sure exactly what happens when Git doesn't know the syntax). Ask "git grep -A14 'long def_ff' xdiff/" for details ;-) This was an attempt to be compatible with stock behaviour of GNU diff: a line that begins with an alpha, _ or $. >> Sometimes it's even in the wrong position, above the @@ numbers. > > That is strange. Do you have a way to reproduce this? That indeed is unusual. If the payload that was identified by the find_func function has a funny escape sequence or something, you may get funkiness like that in the output on the terminal, which we may want to take notice and sanitize in xdl_emit_hunk_hdr(), instead of straight memcpy() there, but I do not see how that would be an issue in a css source. -- 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
