Junio C Hamano <gits...@pobox.com> writes:

> Jonathan Tan <jonathanta...@google.com> writes:
>>> I vaguely recall that there were some discussion on the definition
>>> of "what's a trailer line" with folks from the kernel land, perhaps
>>> while discussing the interpret-trailers topic.  IIRC, when somebody
>>> passes an improved version along, the resulting message's trailer
>>> block may look like this:
>>>     Signed-off-by: Original Author <origi...@author.xz>
>>>     [fixed typo in the variable names]
>>>     Signed-off-by: Somebhody Else <someb...@else.xz>
>>> and an obvious "wish" of theirs was to treat not just RFC2822-like
>>> "a line that begins with token followed by a colon" but also these
>>> short comments as part of the trailer block.  Your original wish in
>>> [*1*] is to also treat "a line that begin with a whitespace that
>>> follows a line that begins with token followed by a colon" as part
>>> of the trailer block and I personally think that is a reasonable
>>> thing to wish for, too.
>> If we allowed arbitrary lines in the trailer block, this would solve
>> my original problem, yes.

Here is an experiment I ran during my lunch break.  The script
(attached) is meant to run in the kernel repository and
for each log messages of each non-merge commit:

 * find its last paragraph, where the definition of paragraph is
   simply "a blank/empty line";

 * inspect if there is at least one RFC2822-header-looking line, or
   a line that begins with "(cherry picked from";

 * dump the ones that do not pass the above criteria.

My cursory look of the output did not spot a legitimate trailer
block that we should have identified.  The output lines shown were
ones that are not signed off at all (e.g. af8c34ce6ae32add that says
"Linux 4.7-rc2"), ones that has three-dash line "---" in them
(e.g. 133d558216d9), ones that has diffstat that should have been
after "---" (e.g. 259307074bfcf1f).

The story is the same if you run it in git.git; the "do we have at
least one rfc2822-header-looking line or '(cherry picked from' line
in the last paragraph? if so, then that is an existing trailer
block" seems to be a good heuristics to cover many cases like

    Signed-off-by: Arnd Bergmann <a...@arndb.de>
    [tomi.valkei...@ti.com: resolved conflicts]
    Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>

    Link 1: https://bugzilla.kernel.org/show_bug.cgi?id=9916
    Link 2: https://bugzilla.kernel.org/show_bug.cgi?id=9399
    Link 3: https://bugzilla.kernel.org/show_bug.cgi?id=11884
    Link 4: https://bugzilla.kernel.org/show_bug.cgi?id=112911
    Signed-off-by: Lv Zheng <lv.zh...@intel.com>
    Tested-by: Chris Bainbridge <chris.bainbri...@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

-- >8 --

git log --no-merges |
perl -e '
        sub flush {
                my ($commit, @lines) = @_;
                my $seen_good = 0;
                for (@lines) {
                        if (/^[-A-Za-z0-9]+: / ||
                            /^\(cherry picked from/) {
                                $seen_good = 1;
                if (!$seen_good) {
                        print "\n$commit\n";
                        for (@lines) {

        my (@lines, $this);
        while (<>) {
                if (/^commit (.*)$/) {
                        my $next = $1;
                        flush($this, @lines);
                        @lines = ();
                        $this = $next;
                if (s/^    //) {
                        if (/^\s*$/) {
                                @lines = ();
                        } else {
                                push @lines, $_;
        if (@lines && $this) {
                flush($this, @lines);

Reply via email to