git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
SOSergei Organov <osv@javad.com>
Date
Nov 23, 2007, 20:18 UTC
Message-ID
<87hcjcra10.fsf@osv.gnss.ru>
In-Reply-To
<7vejegu4in.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 31 quoted lines
> 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.
Previous: Junio C HamanoNext: Junio C Hamano
Message 10 of 14 in “Don't add To: recipients to the Cc: header”
  1. Don't add To: recipients to the Cc: headerAsk Bjørn Hansen, Nov 19, 2007
  2. Ask Bjørn HansenNov 19, 2007
  3. Junio C HamanoNov 20, 2007
  4. Ask Bjørn HansenNov 20, 2007
  5. Junio C HamanoNov 20, 2007
  6. Sergei OrganovNov 20, 2007
  7. Junio C HamanoNov 20, 2007
  8. Sergei OrganovNov 23, 2007
  9. Junio C HamanoNov 23, 2007
  10. Sergei OrganovNov 23, 2007
  11. Junio C HamanoNov 23, 2007
  12. Sergei OrganovNov 26, 2007
  13. Junio C HamanoNov 26, 2007
  14. Sergei OrganovNov 26, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.