Re: [PATCH] Don't add To: recipients to the Cc: header

[Sergei Organov <osv@javad.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Sergei Organov <osv@javad.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Sergei Organov <osv@javad.com> writes:
>>>
>>>> Junio C Hamano <gitster@pobox.com> 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.