r107 - /web/deps/dep3.mdwn

hertzog at users.alioth.debian.org hertzog at users.alioth.debian.org
Mon Oct 5 06:19:42 UTC 2009


Author: hertzog
Date: Mon Oct  5 06:19:41 2009
New Revision: 107

URL: http://svn.debian.org/wsvn/dep/?sc=1&rev=107
Log:
Clarify distinction between fields and header

Thanks to Ben Finney <ben+debian at benfinney.id.au> for the patch.

Modified:
    web/deps/dep3.mdwn

Modified: web/deps/dep3.mdwn
URL: http://svn.debian.org/wsvn/dep/web/deps/dep3.mdwn?rev=107&op=diff
==============================================================================
--- web/deps/dep3.mdwn (original)
+++ web/deps/dep3.mdwn Mon Oct  5 06:19:41 2009
@@ -47,12 +47,13 @@
 
 Structure
 ---------
-The meta-information would be stored in one or two set(s) of RFC-2822-like
-fields (the difference with RFC-2822 is that newlines are meaningful in
-the Description field, they are not simple continuation characters).
-The first set of fields (headers) should start on the first non-empty line
-(after having stripped whitespace characters at the start and end of
-lines).
+
+The meta-information would be stored in one or two headers: sets of
+RFC-2822-like fields. (The difference with RFC 2822 is that newlines
+are meaningful in the Description field, they are not simple
+continuation characters). The first header should start on the first
+non-empty line (after having stripped whitespace characters at the
+start and end of lines).
 
 For patch-systems like dpatch that require the patch to be a standalone
 script, the shebang line is ignored and it is possible to put those fields
@@ -62,12 +63,12 @@
 they start with a space once "`#` " (hash followed by a space) has been
 stripped from the beginning.
 
-Sets of fields always end on the first empty line. Free-form comments can
+A header always ends on the first empty line. Free-form comments can
 follow and should be considered as supplementary lines of the long
-description (see detailed explanations of the field). A second-set of fields
-(pseudo-headers) can start on any new paragraph. A line containing 3 dashes
-(---) should stop the parsing: lines after it are not relevant part of the
-meta-information.
+description (see detailed explanations of the field). A second header
+(the “pseudo-header”) can start on any new paragraph. A line
+containing 3 dashes (---) should stop the parsing: lines after it are
+not relevant part of the meta-information.
 
 Any parser that expect those fields in patch headers should also
 accept non-structured content and simply consider the whole content
@@ -229,8 +230,10 @@
 * 2009-08-24: Add samples and mention difference with RFC-2822 related to
   the Description field.
 * 2009-09-07: Move to CANDIDATE status.
-* 2009-09-26: Modified structure to allow for 2 set of fields (headers and
-  pseudo-headers). Make Subject an alias of Description, From an alias of
+* 2009-09-26: Modified structure to allow for 2 set of fields (the header and
+  pseudo-header). Make Subject an alias of Description, From an alias of
   Author and Acked-by an alias of Reviewed-by. All those changes allow for
   a better compatibility with patches that are VCS changesets embedded in
   mails (notably those generated by git format-patch).
+* 2009-10-05: Clarify the distinction between header and field, by the
+  precedent set in RFC 2822.




More information about the dep-commits mailing list