Junio C Hamano [off-list ref] writes:
* "log --format=%N" and "log --show-notes"
Currently %N expands to the hardcoded "log --show-notes" default format.
We can probably keep it that way. When the user asked for a non default
notes hierarchy (i.e. other than refs/notes/commits), we may want to
adjust "Notes:" string to use "Notes-%s:" to show which hierarchy it came
from, and concatenate them together.
For "log --show-notes" output, we also might want to move the notes to the
header part like I illustrated above in format-patch output, instead of
"start with unindented Notes: and indented body at the end". I.e. instead
of showing this:
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 [off-list ref]
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:
[off-list ref]
which is what 1.6.6 added, showing it like this:
$ git log --notes-ref=amlog -1 4d0cc22
commit 4d0cc2243778b38c3759c6a08f4f1ed64155a070
Author: Junio C Hamano [off-list ref]
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: [off-list ref]
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".
On Fri, Feb 5, 2010 at 11:31 PM, Junio C Hamano [off-list ref] 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 [off-list ref]
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:
[off-list ref]
which is what 1.6.6 added, showing it like this:
$ git log --notes-ref=amlog -1 4d0cc22
commit 4d0cc2243778b38c3759c6a08f4f1ed64155a070
Author: Junio C Hamano [off-list ref]
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: [off-list ref]
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