{"thread":{"id":"10927","subject":"[PATCH] Don't add To: recipients to the Cc: header","startedAt":"2007-11-19T11:00:26Z","lastAt":"2007-11-26T18:29:11Z","messageCount":14,"participants":["Ask Bjørn Hansen","Junio C Hamano","Sergei Organov"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"60288","messageId":"1195470026-7389-1-git-send-email-ask@develooper.com","threadId":"10927","inReplyTo":null,"subject":"[PATCH] Don't add To: recipients to the Cc: header","fromName":"Ask Bjørn Hansen","fromEmail":"ask@develooper.com","sentAt":"2007-11-19T11:00:26Z","receivedAt":"2007-11-19T11:00:26Z","isPatch":true,"sender":{"key":"ask@develooper.com","avatar":"https://gravatar.com/avatar/05ce68433216df7d04bb0d82b7d93b11957e2137e6ed23c4b5bc061d78635f2f?d=mp&s=160"},"body":"\nSigned-off-by: Ask Bjørn Hansen \n---\n git-send-email.perl | 6 +++++-\n 1 files changed, 5 insertions(+), 1 deletions(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 65620ab..530b456 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -557,8 +557,11 @@ sub sanitize_address\n sub send_message\n {\n \tmy @recipients = unique_email_list(@to);\n-\t@cc = (map { sanitize_address($_) } @cc);\n+\t@cc = (grep { my $cc = extract_valid_address($_);\n+\t\t not grep { $cc eq $_ } @recipients\n+\t\t }\n+\t map { sanitize_address($_) }\n+\t @cc);\n \tmy $to = join (\",\\n\\t\", @recipients);\n \t@recipients = unique_email_list(@recipients,@cc,@bcclist);\n \t@recipients = (map { extract_valid_address($_) } @recipients);\n-- \n1.5.3.5.561.g140d\n"},{"id":"60290","messageId":"EE4271C0-CFFA-4714-8F4B-27CBDC33425B@develooper.com","threadId":"10927","inReplyTo":"1195470026-7389-1-git-send-email-ask@develooper.com","subject":"Re: [PATCH] Don't add To: recipients to the Cc: header","fromName":"Ask Bjørn Hansen","fromEmail":"ask@develooper.com","sentAt":"2007-11-19T11:05:37Z","receivedAt":"2007-11-19T11:05:37Z","isPatch":true,"sender":{"key":"ask@develooper.com","avatar":"https://gravatar.com/avatar/05ce68433216df7d04bb0d82b7d93b11957e2137e6ed23c4b5bc061d78635f2f?d=mp&s=160"},"body":"\nOn Nov 19, 2007, at 3:00 AM, Ask Bjørn Hansen wrote:\n\nWhoops. I thought I stopped the mailing of the first patch. It was \nadding whitespace to the end of one of the lines. Sorry about the \nduplication!\n\n\n - ask\n\n-- \nhttp://develooper.com/ - http://askask.com/\n"},{"id":"60394","messageId":"7vr6ill5f1.fsf@gitster.siamese.dyndns.org","threadId":"10927","inReplyTo":"1195470026-7389-1-git-send-email-ask@develooper.com","subject":"Re: [PATCH] Don't add To: recipients to the Cc: header","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-20T07:52:50Z","receivedAt":"2007-11-20T07:52:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ask Bjørn Hansen writes:\n\n> Signed-off-by: Ask Bjørn Hansen \n> ---\n> git-send-email.perl | 6 +++++-\n> 1 files changed, 5 insertions(+), 1 deletions(-)\n>\n> diff --git a/git-send-email.perl b/git-send-email.perl\n> index 65620ab..530b456 100755\n> --- a/git-send-email.perl\n> +++ b/git-send-email.perl\n> @@ -557,8 +557,11 @@ sub sanitize_address\n> sub send_message\n> {\n> \tmy @recipients = unique_email_list(@to);\n> -\t@cc = (map { sanitize_address($_) } @cc);\n> +\t@cc = (grep { my $cc = extract_valid_address($_);\n> +\t\t not grep { $cc eq $_ } @recipients\n> +\t\t }\n> +\t map { sanitize_address($_) }\n> +\t @cc);\n> \tmy $to = join (\",\\n\\t\", @recipients);\n> \t@recipients = unique_email_list(@recipients,@cc,@bcclist);\n> \t@recipients = (map { extract_valid_address($_) } @recipients);\n> -- \n> 1.5.3.5.561.g140d\n\nHow did you prepare and send this patch?\n\nI see 7 preimage lines and 11 postimage lines, although the hunk\nheader claims otherwise.\n\nDid you edit the patch in Emacs diff mode or something?\n"},{"id":"60398","messageId":"7A3DDFA5-085D-4D92-BE96-A405FF1FB029@develooper.com","threadId":"10927","inReplyTo":"7vr6ill5f1.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Don't add To: recipients to the Cc: header","fromName":"Ask Bjørn Hansen","fromEmail":"ask@develooper.com","sentAt":"2007-11-20T09:36:20Z","receivedAt":"2007-11-20T09:36:20Z","isPatch":true,"sender":{"key":"ask@develooper.com","avatar":"https://gravatar.com/avatar/05ce68433216df7d04bb0d82b7d93b11957e2137e6ed23c4b5bc061d78635f2f?d=mp&s=160"},"body":"\nOn Nov 19, 2007, at 23:52, Junio C Hamano wrote:\n\n> How did you prepare and send this patch?\n\ngit format-patch + tweak in emacs.\n\n> I see 7 preimage lines and 11 postimage lines, although the hunk\n> header claims otherwise.\n>\n> Did you edit the patch in Emacs diff mode or something?\n\nIndeed! I take it you've seen that particular way of botching it \nbefore. :-)\n\nWhen I was about to send the patch I realized I had added whitespace \nat the end of one of the lines. Ironically then I ended up just \nsending the messed up patch because I couldn't apply it to my working \ncopy after doing a reset. Being a new git user I convinced myself \nthat I had messed up the reset rather than the patch. Doh. My \napologies! A new patch should be on the list momentarily.\n\n\n - ask\n\n-- \nhttp://develooper.com/ - http://askask.com/\n"},{"id":"60431","messageId":"7v8x4slovk.fsf@gitster.siamese.dyndns.org","threadId":"10927","inReplyTo":"7A3DDFA5-085D-4D92-BE96-A405FF1FB029@develooper.com","subject":"Re: [PATCH] Don't add To: recipients to the Cc: header","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-20T19:04:47Z","receivedAt":"2007-11-20T19:04:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ask Bjørn Hansen writes:\n\n> On Nov 19, 2007, at 23:52, Junio C Hamano wrote:\n>\n>> How did you prepare and send this patch?\n>\n> git format-patch + tweak in emacs.\n>\n>> I see 7 preimage lines and 11 postimage lines, although the hunk\n>> header claims otherwise.\n>>\n>> Did you edit the patch in Emacs diff mode or something?\n>\n> Indeed! I take it you've seen that particular way of botching it\n> before. :-)\n\nYes and a heavy advocate of Emacs on this list wanted to get a\nbreakage example out of me which I forgot to supply but now we\nhave it. Unfortunately I do not offhand recall who it was.\n\n> When I was about to send the patch I realized I had added whitespace\n> at the end of one of the lines. Ironically then I ended up just\n> sending the messed up patch because I couldn't apply it to my working\n> copy after doing a reset. Being a new git user I convinced myself\n> that I had messed up the reset rather than the patch. Doh. My\n> apologies! A new patch should be on the list momentarily.\n\nOops, forgot to say \"no need to resend\". I asked only because I\nwanted an independent datapoint for Emacs diff mode breakage.\n"},{"id":"60433","messageId":"87ejekzpx3.fsf@osv.gnss.ru","threadId":"10927","inReplyTo":"7v8x4slovk.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Don't add To: recipients to the Cc: header","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2007-11-20T19:18:32Z","receivedAt":"2007-11-20T19:18:32Z","isPatch":true,"sender":{"key":"osv@javad.com","avatar":null},"body":"Junio C Hamano writes:\n[...]\n> Oops, forgot to say \"no need to resend\". I asked only because I\n> wanted an independent datapoint for Emacs diff mode breakage.\n\nI bet I can damage any patch using any editor ;)\n\nMore interesting is what version of Emacs it was?\n\n-- \nSergei.\n"},{"id":"60439","messageId":"7vr6ikk6rf.fsf@gitster.siamese.dyndns.org","threadId":"10927","inReplyTo":"87ejekzpx3.fsf@osv.gnss.ru","subject":"Re: [PATCH] Don't add To: recipients to the Cc: header","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-20T20:21:24Z","receivedAt":"2007-11-20T20:21:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergei Organov writes:\n\n> Junio C Hamano writes:\n> [...]\n>> Oops, forgot to say \"no need to resend\". I asked only because I\n>> wanted an independent datapoint for Emacs diff mode breakage.\n>\n> I bet I can damage any patch using any editor ;)\n>\n> More interesting is what version of Emacs it was?\n\nTo be fair and honest, I do not think there is a simple fix for\nthis, although it probably is possible to fix it.\n\nWhat is causing the \"breakage\" is the fact that format-patch\noutput ends with the signature delimiter line \"^-- $\" that\nimmediately follows the patch text. The number of preimage\nlines recorded in the hunk header of course does not initially\ncount it, but you are asking the diff editing mode to help you\nedit the patch.\n\nIn diff editing mode, you can not only edit the contents of\npostimage lines, but also add and delete the preimage and\npostimage lines, and the diff editimg mode recounts the lines\nand adjusts the number of lines recorded in the hunk header when\nyou do it. It is very handy if it worked reliably (and often\nit does).\n\nBut if you edit the last hunk of the format-patch output, unless\nthe editor very carefully keeps track of what you edited and\nwhat was in the original, it is understandable that it would\nmistake the signature delimiter line as the last preimage line\nthat is \"^- $\", and ends up miscounting the length of the hunk.\n\nThe signature delimiter was there from the beginning in the\npatch file, but outside of the hunk in question. We could argue\nthat it is a bug to mistake that as a preimage line added by the\nuser (after all the editor knows what was modified and what was\nfrom the beginning), but it still is understandable.\n"},{"id":"60769","messageId":"87lk8orgpm.fsf@osv.gnss.ru","threadId":"10927","inReplyTo":"7vr6ikk6rf.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Don't add To: recipients to the Cc: header","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2007-11-23T17:53:41Z","receivedAt":"2007-11-23T17:53:41Z","isPatch":true,"sender":{"key":"osv@javad.com","avatar":null},"body":"Junio C Hamano writes:\n\n> Sergei Organov writes:\n>\n>> Junio C Hamano writes:\n>> [...]\n>>> Oops, forgot to say \"no need to resend\". I asked only because I\n>>> wanted an independent datapoint for Emacs diff mode breakage.\n>>\n>> I bet I can damage any patch using any editor ;)\n>>\n>> More interesting is what version of Emacs it was?\n>\n> To be fair and honest, I do not think there is a simple fix for\n> this, although it probably is possible to fix it.\n>\n> What is causing the \"breakage\" is the fact that format-patch\n> output ends with the signature delimiter line \"^-- $\" that\n> immediately follows the patch text.\n\nExactly. What causes breakage is the fact that the '-' character (as\nwell as '+', ' ', '!', '#', and '\\'), being the first symbol of a line\nhas special meaning in the diff format.\n\nTherefore it seems that format-patch should better put one empty line\nafter the last diff hunk and before the signature. Any objections?\n\n-- \nSergei.\n"},{"id":"60782","messageId":"7vejegu4in.fsf@gitster.siamese.dyndns.org","threadId":"10927","inReplyTo":"87lk8orgpm.fsf@osv.gnss.ru","subject":"Re: [PATCH] Don't add To: recipients to the Cc: header","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-23T19:48:48Z","receivedAt":"2007-11-23T19:48:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergei Organov writes:\n\n> Junio C Hamano writes:\n>\n>> Sergei Organov writes:\n>>\n>>> Junio C Hamano writes:\n>>> [...]\n>>>> Oops, forgot to say \"no need to resend\". I asked only because I\n>>>> wanted an independent datapoint for Emacs diff mode breakage.\n>>>\n>>> I bet I can damage any patch using any editor ;)\n>>>\n>>> More interesting is what version of Emacs it was?\n>>\n>> To be fair and honest, I do not think there is a simple fix for\n>> this, although it probably is possible to fix it.\n>>\n>> What is causing the \"breakage\" is the fact that format-patch\n>> output ends with the signature delimiter line \"^-- $\" that\n>> immediately follows the patch text.\n>\n> Exactly. What causes breakage is the fact that the '-' character (as\n> well as '+', ' ', '!', '#', and '\\'), being the first symbol of a line\n> has special meaning in the diff format.\n\nThat is correct only if they appear inside a hunk. The number\nof preimage and postimage lines in a hunk is recorded on the\nhunk header line --- tools are given enough information to tell\na line that begins with a SP (or '+' or '-') outside a patch\nfrom another such line that is inside the patch.\n\nThe diff editing mode of Emacs, at least the version that caused\nthis issue, however did not make use of that information.\nThat's the breakage. Not format-patch output.\n"},{"id":"60785","messageId":"87hcjcra10.fsf@osv.gnss.ru","threadId":"10927","inReplyTo":"7vejegu4in.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Don't add To: recipients to the Cc: header","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2007-11-23T20:18:03Z","receivedAt":"2007-11-23T20:18:03Z","isPatch":true,"sender":{"key":"osv@javad.com","avatar":null},"body":"Junio C Hamano writes:\n\n> Sergei Organov writes:\n>\n>> Junio C Hamano writes:\n>>\n>>> Sergei Organov writes:\n>>>\n>>>> Junio C Hamano writes:\n>>>> [...]\n>>>>> Oops, forgot to say \"no need to resend\". I asked only because I\n>>>>> wanted an independent datapoint for Emacs diff mode breakage.\n>>>>\n>>>> I bet I can damage any patch using any editor ;)\n>>>>\n>>>> More interesting is what version of Emacs it was?\n>>>\n>>> To be fair and honest, I do not think there is a simple fix for\n>>> this, although it probably is possible to fix it.\n>>>\n>>> What is causing the \"breakage\" is the fact that format-patch\n>>> output ends with the signature delimiter line \"^-- $\" that\n>>> immediately follows the patch text.\n>>\n>> Exactly. What causes breakage is the fact that the '-' character (as\n>> well as '+', ' ', '!', '#', and '\\'), being the first symbol of a line\n>> has special meaning in the diff format.\n>\n> That is correct only if they appear inside a hunk. The number\n> of preimage and postimage lines in a hunk is recorded on the\n> hunk header line --- tools are given enough information to tell\n> a line that begins with a SP (or '+' or '-') outside a patch\n> from another such line that is inside the patch.\n\nYeah, it's one valid interpretation. Here is another one:\n\n \"The chunk range for the original should be the sum of all contextual\n and deletion (including changed) chunk lines. The chunk range for the\n new file should be a sum of all contextual and addition (including\n changed) chunk lines. If chunk size information does not correspond\n with the number of lines in the hunk, then the diff could be\n considered invalid and be rejected.\"\n\ntaken from here: \n\nThe above implies that a tool should be able to determine the \"end of\nhunk\" without using the hunk header information. This is rather hard to\ndo with current format-patch output, and it's impossible to do if there\nare no \"unchanged context\" lines at all (i.e., format-patch -U0).\n\n> The diff editing mode of Emacs, at least the version that caused\n> this issue, however did not make use of that information.\n> That's the breakage. Not format-patch output.\n\nIMHO it's rather useless to argue about it without strict definition of\ncorrect format of a patch (do you have one?). However, it's easy to add\nan empty line for format-patch and very difficult, if not impossible,\nfor Emacs to handle this without such a line.\n\nTherefore I repeat my question: are there any objections to add such an\nempty line by format-patch?\n\n-- \nSergei.\n"},{"id":"60796","messageId":"7vejegsejz.fsf@gitster.siamese.dyndns.org","threadId":"10927","inReplyTo":"87hcjcra10.fsf@osv.gnss.ru","subject":"Re: [PATCH] Don't add To: recipients to the Cc: header","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-23T23:54:56Z","receivedAt":"2007-11-23T23:54:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergei Organov writes:\n\n> Yeah, it's one valid interpretation. Here is another one:\n> ...\n> taken from here: \n\nRants about how dangerous GNU patch liberally (mis)interprets a\nbroken patch and git-apply is written deliberately more strict\nhave been repeated on this list, and I would not steal it from\nLinus in this response.\n\n>> The diff editing mode of Emacs, at least the version that caused\n>> this issue, however did not make use of that information.\n>\n> IMHO it's rather useless to argue about it without strict definition of\n> correct format of a patch (do you have one?)\n\nYes. 2004 POSIX does not talk about unified context, but Austin\ngroup's SD5-XCU-ERN-103/120 has additions to define unified\ncontext and renames the traditional '-c' output to \"copied\ncontext\". Obviously it defines what the numbers on the hunk\nheader lines mean quite precisely. GNU folks even managed to\ninsert text that allows a completely empty line (not a line with\na single SP on it) to express a context line that is empty,\nwhich means...\n\n> However, it's easy to add\n> an empty line for format-patch and very difficult, if not impossible,\n> for Emacs to handle this without such a line.\n>\n> Therefore I repeat my question: are there any objections to add such an\n> empty line by format-patch?\n\n... there is a strong objection, if you are talking about adding\nan empty line before \"-- \\n\" that is in front of the GIT version\nsignature: such an empty line would not help at all. A broken\nimplementation will just skip over such an empty line, counting\nit as a line common to both preimage and postimage, and will\nstill miscount the e-mail signature separator \"-- \\n\" as a line\nremoved from the preimage.\n\nHaving said that, the _ONLY_ reason I made format-patch end its\noutput with \"-- \\n\" with GIT version was because I wanted to do\nan informal census of the user community by observing mailing\nlist traffic of projects that use git. The tool has since\nmatured, and census in such a form is not so important anymore.\n\nIf we wanted to have a workaround to this issue, we could simply\nremove these last two lines, and that would a be much better one\nthan an extra blank line. I do not have a strong objection to\nsuch a change, but you would need to adjust the tests. The most\ndepressing part of the whole exercise would be to make sure that\nthe adjustments to the tests are correct.\n"},{"id":"60937","messageId":"87wss5p177.fsf@osv.gnss.ru","threadId":"10927","inReplyTo":"7vejegsejz.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Don't add To: recipients to the Cc: header","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2007-11-26T13:48:28Z","receivedAt":"2007-11-26T13:48:28Z","isPatch":true,"sender":{"key":"osv@javad.com","avatar":null},"body":"Junio C Hamano writes:\n\n> Sergei Organov writes:\n>\n>> Yeah, it's one valid interpretation. Here is another one:\n>> ...\n>> taken from here: \n>\n> Rants about how dangerous GNU patch liberally (mis)interprets a\n> broken patch and git-apply is written deliberately more strict\n> have been repeated on this list, and I would not steal it from\n> Linus in this response.\n\nYeah, being strict when applying patches is a good idea, I agree, though\nI fail to see how it is relevant to the problem at hand. I mean that if\nwe either remove the signature or put an empty line before it, the\nresulting file won't become less conforming to the patch format, isn't\nit?\n\n>>> The diff editing mode of Emacs, at least the version that caused\n>>> this issue, however did not make use of that information.\n>>\n>> IMHO it's rather useless to argue about it without strict definition of\n>> correct format of a patch (do you have one?)\n>\n> Yes. 2004 POSIX does not talk about unified context, but Austin\n> group's SD5-XCU-ERN-103/120 has additions to define unified\n> context and renames the traditional '-c' output to \"copied\n> context\". Obviously it defines what the numbers on the hunk\n> header lines mean quite precisely.\n\nI don't argue it. But the descriptions of the format I've seen suggest\nthat the hunks of the proper unified diff format could be easily\nsyntactically separated, thus providing a way to check a patch for\ncorrectness by comparing what is written in headers with what is\ngathered by syntactic analysis. Git's signature makes this rather\ndifficult.\n\nIMHO, putting extra lines that don't follow the patch format precisely\nis an extension, and being an extension, it should better be compatible\nwith as many tools as possible, and this signature of the format-patch\nis known to break at least one tool. Unfortunately I don't have the\ndocument you mention, but I doubt it discusses extensions, and therefore\nI'm afraid we won't be able to conclude from it if putting signature\njust after the hunk is allowed by the format or not.\n\nAs for Emacs, the problem is not that it doesn't know what the numbers\nof the hunk header lines mean, but that it needs to re-build them from a\npatch that has been arbitrary edited and could potentially be broken\nfrom the beginning. Therefore, it needs hunks to be clearly\nsyntactically separated to rebuild header numbers from the context.\n\n> GNU folks even managed to insert text that allows a completely empty\n> line (not a line with a single SP on it) to express a context line\n> that is empty, which means...\n\nReally? That's a surprise for me. What I can tell for sure, Emacs' diff\nmode doesn't support this, as it does interpret plain empty line as a\nhunk delimiter, at least in Emacs 22.1.\n\n[...]\n>> Therefore I repeat my question: are there any objections to add such an\n>> empty line by format-patch?\n>\n> ... there is a strong objection, if you are talking about adding\n> an empty line before \"-- \\n\" that is in front of the GIT version\n> signature: such an empty line would not help at all.\n\nYes, I'm talking about exactly this, and the fact is that it does help,\nat least in Emacs case. [How comes you think I didn't check it before\nposting?!]\n\n> A broken implementation will just skip over such an empty line,\n> counting it as a line common to both preimage and postimage, and will\n> still miscount the e-mail signature separator \"-- \\n\" as a line\n> removed from the preimage.\n\nEmacs doesn't do it when empty line is present, -- it considers empty\nline as hunk delimiter (along with any line that doesn't start with ' ',\n'+', '-', or '!'). BTW, it counts lines starting with either '#' or '\\'\nas comments, i.e., just ignores them when counting the number of lines\nin the hunk.\n\n> If we wanted to have a workaround to this issue, we could simply\n> remove these last two lines, and that would a be much better one\n> than an extra blank line.\n\nWhy? I think it's nice idea to put git version as signature, and I see\nno reason to remove it.\n\nBesides, if empty line is put there before the signature, it'd be more\nreadable for human beings as well, as humans seem to prefer to put empty\nline before their signature anyway.\n\n-- \nSergei.\n"},{"id":"60946","messageId":"7v3autgd8q.fsf@gitster.siamese.dyndns.org","threadId":"10927","inReplyTo":"87wss5p177.fsf@osv.gnss.ru","subject":"Re: [PATCH] Don't add To: recipients to the Cc: header","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-26T16:53:09Z","receivedAt":"2007-11-26T16:53:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergei Organov writes:\n\n>> GNU folks even managed to insert text that allows a completely empty\n>> line (not a line with a single SP on it) to express a context line\n>> that is empty, which means...\n>\n> Really? That's a surprise for me. What I can tell for sure, Emacs' diff\n> mode doesn't support this, as it does interpret plain empty line as a\n> hunk delimiter, at least in Emacs 22.1.\n\nSee b507b465f7831612b9d9fc643e3e5218b64e5bfa (git-apply: prepare for\nupcoming GNU diff -u format change). Around the time that eventually\nlead to this commit (mid October 2006) there was a discussion on this\nmailing list on the issue, too. I do not doubt you checked with your\nversion of Emacs diff mode that it does not support this yet, but it's\nonly prudent to assume that a new version someday will.\n"},{"id":"60951","messageId":"8763zoq2rs.fsf@osv.gnss.ru","threadId":"10927","inReplyTo":"7v3autgd8q.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Don't add To: recipients to the Cc: header","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2007-11-26T18:29:11Z","receivedAt":"2007-11-26T18:29:11Z","isPatch":true,"sender":{"key":"osv@javad.com","avatar":null},"body":"Junio C Hamano writes:\n\n> Sergei Organov writes:\n>\n>>> GNU folks even managed to insert text that allows a completely empty\n>>> line (not a line with a single SP on it) to express a context line\n>>> that is empty, which means...\n>>\n>> Really? That's a surprise for me. What I can tell for sure, Emacs' diff\n>> mode doesn't support this, as it does interpret plain empty line as a\n>> hunk delimiter, at least in Emacs 22.1.\n>\n> See b507b465f7831612b9d9fc643e3e5218b64e5bfa (git-apply: prepare for\n> upcoming GNU diff -u format change). Around the time that eventually\n> lead to this commit (mid October 2006) there was a discussion on this\n> mailing list on the issue, too. I do not doubt you checked with your\n> version of Emacs diff mode that it does not support this yet, but it's\n> only prudent to assume that a new version someday will.\n\nThanks, -- it was interesting to read corresponding discussions.\n\nDue to this change in GNU diff, it seems that empty line is indeed a\nwrong choice for syntactic hunk separator :( I wonder if there is a\ncommon way to say \"here the patch ends\" then[1]? My best guess is that\n\n===\n\nwill do.\n\n[1] I've checked bzr and hg. Bzr uses empty line for that (followed by\n\"# Begin bundle\" line) in their \"merge directive\" format. Not\nEmacs-friendly either :( Hg's \"export\" just EOFs after the patch.\n\n-- \nSergei.\n"}]}