Sergei Organov <osv@xxxxxxxxx> writes: > Yeah, it's one valid interpretation. Here is another one: > ... > taken from here: <http://www.answers.com/topic/diff?cat=technology> Rants about how dangerous GNU patch liberally (mis)interprets a broken patch and git-apply is written deliberately more strict have been repeated on this list, and I would not steal it from Linus in this response. >> The diff editing mode of Emacs, at least the version that caused >> this issue, however did not make use of that information. > > IMHO it's rather useless to argue about it without strict definition of > correct format of a patch (do you have one?) Yes. 2004 POSIX does not talk about unified context, but Austin group's SD5-XCU-ERN-103/120 has additions to define unified context and renames the traditional '-c' output to "copied context". Obviously it defines what the numbers on the hunk header lines mean quite precisely. GNU folks even managed to insert text that allows a completely empty line (not a line with a single SP on it) to express a context line that is empty, which means... > However, it's easy to add > an empty line for format-patch and very difficult, if not impossible, > for Emacs to handle this without such a line. > > Therefore I repeat my question: are there any objections to add such an > empty line by format-patch? ... there is a strong objection, if you are talking about adding an empty line before "-- \n" that is in front of the GIT version signature: such an empty line would not help at all. A broken implementation will just skip over such an empty line, counting it as a line common to both preimage and postimage, and will still miscount the e-mail signature separator "-- \n" as a line removed from the preimage. Having said that, the _ONLY_ reason I made format-patch end its output with "-- \n" with GIT version was because I wanted to do an informal census of the user community by observing mailing list traffic of projects that use git. The tool has since matured, and census in such a form is not so important anymore. If we wanted to have a workaround to this issue, we could simply remove these last two lines, and that would a be much better one than an extra blank line. I do not have a strong objection to such a change, but you would need to adjust the tests. The most depressing part of the whole exercise would be to make sure that the adjustments to the tests are correct. - 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
