On Fri, Feb 5, 2010 at 11:31 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Giuseppe was wondering about multi-line thing, so the illustration should > be adjusted to match the "format-patch" example to show a multi-line note, > I think. Here is what I meant. > > Instead of showing: > > $ git log --notes-ref=amlog -1 4d0cc22 > commit 4d0cc2243778b38c3759c6a08f4f1ed64155a070 > Author: Junio C Hamano <gitster@xxxxxxxxx> > Date: Thu Feb 4 11:10:44 2010 -0800 > > fast-import: count --max-pack-size in bytes > > Similar in spirit to 07cf0f2 (make --max-pack-size argument to 'git > ... > > Notes: > pulled on Fri Feb 5 07:36:12 2010 -0800 > from git://git.bogomips.org/git-svn.git/ > Notes-amlog: > <7v4olwbyvf.fsf_-_@xxxxxxxxxxxxxxxxxxxxxxxx> > > which is what 1.6.6 added, showing it like this: > > $ git log --notes-ref=amlog -1 4d0cc22 > commit 4d0cc2243778b38c3759c6a08f4f1ed64155a070 > Author: Junio C Hamano <gitster@xxxxxxxxx> > Date: Thu Feb 4 11:10:44 2010 -0800 > Notes: pulled on Fri Feb 5 07:36:12 2010 -0800 > from git://git.bogomips.org/git-svn.git/ > Notes-amlog: <7v4olwbyvf.fsf_-_@xxxxxxxxxxxxxxxxxxxxxxxx> > > fast-import: count --max-pack-size in bytes > > Similar in spirit to 07cf0f2 (make --max-pack-size argument to 'git > ... > > might be easier to see. After all, notes are metainformation on commits, > and people who are interested will look at the header, and those who are > not will skim over the block of text at the beginning, knowing that is > where all the metainformation is. > > But this is just "might", not "should---I strongly believe". I'm not convinced. I believe format-patch output should be as close as possible to RFC2822 compliance, given how it can be used as basis for actual email. According to the RFC, lines should be no more than 78 characters and must be less than 998. The 'one space indent on newline', if I'm not mistaken, is a way to indicate a _wrapped_ single line header, rather than a multi-line one. A scenario such as the following is thus possible: format-patch creates a single-line header which is longer than 78 characters (X-Git-Notes-somerefname: 70ish characters line). The patch gets sent by email, and a properly configured send-email sends the X-Git-Notes* headers through (BTW, this should probably be added to the notes/send-email TODO). Some intermediate forwarder or user agent decides to rewrap the longish line so that it isn't longer than 78 characters. The user saves the raw email and uses git am to apply it -> oops, the single line note has become a two-liner. If we use the convention (at least in format-patch, not necessarily in log) of one header line per notes line we should be more on the safe side. It would also allow us to keep the headers wrapped at < 78 characters which is nice for legibility on terminals. -- Giuseppe "Oblomov" Bilotta -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html