Change Details

GnuPG has its own commit message style that is highly structured and contains valuable information. By integrating it in arc and phabricator, we can preserve and enhance it: * Parse existing commit messages (see https://secure.phabricator.com/T5132#69200) ** Treat "gnupg-bug-id: xxx, yyy" like "Ref Txxx", "Ref Tyyy" ** Parse the one-line summary and changelog section as summary. ** Parse everything between "--" and the keyword list as "Test Plan". ** Maybe parse keywords in first line and add them as projects. ** Maybe link files in changelog-style section to the patch units or the files in the repo browser (if easy to do). * Extend gnupg commit message format by new featuresw ** Add new keyword field "fixes-bug-id: xxx, yyy" and treat it like "Fixes xxx", "Fixes yyy" (autoclose). ** Add new keyword field "reviewers: user1, user2". ** Add new keyword field "patch-id: Dxxx" (this will be automatically added by arc and links the commit to a patch) ** Document new keyword in doc/HACKING * Changes in arc ** Create a gnupg commit style template on initial commit message editing ** Create new patch-id instead of "Differential revision:"

GnuPG has its own commit message style that is highly structured and contains valuable information. By integrating it in arc and phabricator, we can preserve and enhance it: * Parse existing commit messages (see https://secure.phabricator.com/T5132#69200) ** Treat "gnupg-bug-id: xxx, yyy" like "Ref Txxx", "Ref Tyyy" ** Parse the one-line summary and changelog section as summary. ** Parse everything between "--" and the keyword list as "Test Plan". ** Maybe parse keywords in first line and add them as projects. ** Maybe link files in changelog-style section to the patch units or the files in the repo browser (if easy to do). * Extend gnupg commit message format by new featuresw ** Add new keyword field "fixes-bug-id: xxx, yyy" and treat it like "Fixes xxx", "Fixes yyy" (autoclose). ** Add new keyword field "reviewers: user1, user2". ** Add new keyword field "auditors: user1, user2" to request a post-commit audit. ** Add new keyword field "patch-id: Dxxx" (this will be automatically added by arc and links the commit to a patch) ** Document new keyword in doc/HACKING * Changes in arc ** Create a gnupg commit style template on initial commit message editing ** Create new patch-id instead of "Differential revision:"

GnuPG has its own commit message style that is highly structured and contains valuable information. By integrating it in arc and phabricator, we can preserve and enhance it: * Parse existing commit messages (see https://secure.phabricator.com/T5132#69200) ** Treat "gnupg-bug-id: xxx, yyy" like "Ref Txxx", "Ref Tyyy" ** Parse the one-line summary and changelog section as summary. ** Parse everything between "--" and the keyword list as "Test Plan". ** Maybe parse keywords in first line and add them as projects. ** Maybe link files in changelog-style section to the patch units or the files in the repo browser (if easy to do). * Extend gnupg commit message format by new featuresw ** Add new keyword field "fixes-bug-id: xxx, yyy" and treat it like "Fixes xxx", "Fixes yyy" (autoclose). ** Add new keyword field "reviewers: user1, user2". ** Add new keyword field "auditors: user1, user2" to request a post-commit audit. ** Add new keyword field "patch-id: Dxxx" (this will be automatically added by arc and links the commit to a patch) ** Document new keyword in doc/HACKING * Changes in arc ** Create a gnupg commit style template on initial commit message editing ** Create new patch-id instead of "Differential revision:"