proposal: commit message footers for additional ui context #5

what?#

commit message footers are lines of Key: Value pairs typically found at the end of a git commit message. they provide structured, often machine-readable, metadata about the commit, supplementing the main commit summary and body.

this proposal adds support for placing, parsing and utilizing git commit message footers such as:

• Submitted-by: <name> <email>
• Co-authored-by: <name> <email>
• Pull-Id: <pull id>
• Signed-off-by: <name> <email>
• Reviewed-by: <name> <email>
• Merged-by: <name> <email>
• Fixes: <issue id>
• Closes: <issue id>

why?#

in general, this will provide more context in commit messages, for a richer repository browsing experience.

• better attribution: visually represent all contributors to a commit when Co-authored-by and Submitted-by are present.
• enhanced traceability: link directly to pull requests using Pull-Id, streamlining navigation between the merged commit and the source PR.
• issue integration: link to issues using Fixes: or Closes:, offering quick access to related discussions and requirements.
• richer commit view: display more metadata directly in the UI, reducing the need for users to manually parse commit messages for this information.

how?#

the implementation can be broken down into the following changes:

1. pull merge workflow: when merging a pull request, add additional footers to the commit message. this will require appview passing additional pull request metadata to knotserver in the merge endpoint, which can be added to the commit message as footers.

2. rendering commit context: parse the commit message for the footers and display them in the commit view as appropriate:

   • Co-authored-by can be displayed as additional author names alongside the primary committer.
   • Pull-id can be rendered as a clickable link to the corresponding pull.
   • Fixes: / Closes: can be rendered as clickable links to the issues.
   • Reviewed-by, Merged-by, Submitted-by could be displayed in a dedicated metadata section of the commit view or rendered as a tooltip on hover

open questions#

• spec for the footers that are essential for the initial implementation
• how to handle malformed footer values

let me know if this is something we would like to implement. i'd be happy to write up a concrete spec and open a pull for this.