I think you'll find this latest revision even more robust: https://gist.github.com/ilovezfs/0c364ceff6f2085ff89c/192a6e78e7b906a14b4d5ec961f3489d454401b2
It identified a commit in illumos-gate that breaks the rule against a blank line :) https://github.com/illumos/illumos-gate/commit/b9071c34cb3102be3bbda85c57015ea13193aa6b.patch #!/usr/bin/env awk -f BEGIN { fout="/dev/stdout"; blank=0; } function flush_blanks() { while (blank != 0) { print ""; blank--; } } $1 ~ /^[0-9]{7}/ { fout="/dev/stdout"; flush_blanks(); hitreviewsection=0; hitbody=0; } /^$/ { if (hitreviewsection == 0 && NR == 2) { blank++; next; } } /^Reviewed by:|^Approved by:|^Reivewed/ { hitreviewsection=1; fout="/dev/stdout"; } !/^Reviewed by:|^Approved by:|^Reivewed/ && !/^$/ { if (hitreviewsection == 1 && hg != 1) { fout="/dev/null"; hitbody=1; } } /^$/ && hitbody == 0 { blank++; fout="/dev/null"; } /--HG--/ { fout="/dev/stdout"; hg=1; flush_blanks(); } { print $0 > fout; } END { if (hitbody == 0 || hg == 1 || NR == 2) flush_blanks(); } On Dec 22, 2015, at 11:23 PM, ilove zfs <[email protected]> wrote: This seems to do the trick: https://gist.github.com/ilovezfs/0c364ceff6f2085ff89c#file-illumos-commit-message-style-awk Inline example: git log -n 1 --format=%B | awk 'BEGIN { fout="/dev/stdout" } /^$/ {next} /^Reviewed by:|^Approved by:/ { hitreviewsection=1 } !/^Reviewed by:|^Approved by:/ { if (hitreviewsection == 1) fout="/dev/null" } { print $0 > fout }' | git commit --amend -F - On Dec 22, 2015, at 10:41 AM, Matthew Ahrens <[email protected]> wrote: FYI, Currently I'm doing: git log -n 1 --format=%B | awk '/^$/ {exit} {print $0}' >$tmpfile Your command worked on a message like: 6513 partially filled holes lose birth time Reviewed by: Matthew Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> If a ZFS object contains a hole at level one, and then a data block is results in: 6513 partially filled holes lose birth time Reviewed by: Matthew Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> But it mangles it if there's more than one bug listed (which is rare, but valid): 6513 partially filled holes lose birth time 1234 another commit Reviewed by: Matthew Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> If a ZFS object contains a hole at level one, and then a data block is results in: 6513 partially filled holes lose birth time Also, if I use it on the current style message, it subtly mangles it: 6513 partially filled holes lose birth time Reviewed by: Matthew Ahrens <[email protected]> Reviewed by: George Wilson <[email protected]> If a ZFS object contains a hole at level one, and then a data block is results in: 6513 partially filled holes lose birth time Reviewed by: George Wilson <[email protected]> I'm not great with sed or awk; any ideas how to improve the robustness of this script? --matt On Tue, Dec 22, 2015 at 6:38 AM, ilove zfs <[email protected]> wrote: Assuming the commit is HEAD and the entire message is exactly how you want it, except for the extra line, you should be able to do git log --pretty=format:"%B" HEAD^..HEAD | sed -e '2,2d' -e '/^$/q' | sed -e '/^\s*$/d' | git commit --amend -F - On Dec 21, 2015, at 11:32 PM, Matthew Ahrens <[email protected]> wrote: It needs that format in illumos. So I would need to augment my script to remove the blank line when creating the illumos commit message.. Let me know if you can help with that. --matt On Monday, December 21, 2015, ilove zfs <[email protected]> wrote: Even when the original commit has a blank line after the subject, the finalized commits seem to always be missing the blank line after the subject. This ends up causing problems for git format-patch/git am, git log, git rebase, etc. because the "Reviewed by" section is treated as if it's part of the subject. I'm wondering if there's some change that could be made to the the RTI commit finalization process to ensure that a blank line makes it in there. Example: Without a blank line: bash-3.2$ git log --pretty=format:"%s" HEAD^..HEAD 6529 Properly handle updates of variably-sized SA entries. Reviewed by: Brian Behlendorf <[email protected]> Reviewed by: Matthew Ahrens <[email protected]> Reviewed by: Ned Bass <[email protected]> Reviewed by: Tim Chase <[email protected]> With a blank line: bash-3.2$ git log --pretty=format:"%s" HEAD^..HEAD 6529 Properly handle updates of variably-sized SA entries. https://github.com/behlendorf/openzfs/commit/ba08234ca691208cc19ae447e6330f263bd93ea3.patch https://github.com/illumos/illumos-gate/commit/e7e978b1f75353cb29673af9b35453c20c2827bf.patch https://github.com/openzfs/openzfs/commit/4237281765aa7b431884ef4f566d98bbee07948c.patch
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
