Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergei Organov <osv@xxxxxxxxx> writes: > >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> >>> Sergei Organov <osv@xxxxxxxxx> writes: >>> >>>> Junio C Hamano <gitster@xxxxxxxxx> writes: >>>> [...] >>>>> Oops, forgot to say "no need to resend". I asked only because I >>>>> wanted an independent datapoint for Emacs diff mode breakage. >>>> >>>> I bet I can damage any patch using any editor ;) >>>> >>>> More interesting is what version of Emacs it was? >>> >>> To be fair and honest, I do not think there is a simple fix for >>> this, although it probably is possible to fix it. >>> >>> What is causing the "breakage" is the fact that format-patch >>> output ends with the signature delimiter line "^-- $" that >>> immediately follows the patch text. >> >> Exactly. What causes breakage is the fact that the '-' character (as >> well as '+', ' ', '!', '#', and '\'), being the first symbol of a line >> has special meaning in the diff format. > > That is correct only if they appear inside a hunk. The number > of preimage and postimage lines in a hunk is recorded on the > hunk header line --- tools are given enough information to tell > a line that begins with a SP (or '+' or '-') outside a patch > from another such line that is inside the patch. Yeah, it's one valid interpretation. Here is another one: "The chunk range for the original should be the sum of all contextual and deletion (including changed) chunk lines. The chunk range for the new file should be a sum of all contextual and addition (including changed) chunk lines. If chunk size information does not correspond with the number of lines in the hunk, then the diff could be considered invalid and be rejected." taken from here: <http://www.answers.com/topic/diff?cat=technology> The above implies that a tool should be able to determine the "end of hunk" without using the hunk header information. This is rather hard to do with current format-patch output, and it's impossible to do if there are no "unchanged context" lines at all (i.e., format-patch -U0). > The diff editing mode of Emacs, at least the version that caused > this issue, however did not make use of that information. > That's the breakage. Not format-patch output. IMHO it's rather useless to argue about it without strict definition of correct format of a patch (do you have one?). 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? -- Sergei. - 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
