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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 23, 2007, 23:54 UTC
Message-ID: <7vejegsejz.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <87hcjcra10.fsf@osv.gnss.ru>

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.

Show 5 quoted lines

>> 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...

Show 6 quoted lines

> 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.