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

[Junio C Hamano <gitster@pobox.com>]

Sergei Organov <osv@javad.com> 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.