proposal: commit message footers for additional ui context #96

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:

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.
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.

Reviewed-by would require implementing the notion of (assigned) reviewers in the pull request flow; perhaps this can be done in a later pass.

Agreed.

Co-authored-by is tricky: it's a social convention. How and when would that get set?

For the initial implementation, this can be a manually added footer, with the appview just rendering it on the UI. This is similar to what github does (https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors).

Later, we can automatically set this when there are multiple authors in a pull, i.e, there are commits from multiple authors or commits with co-authors in the source branch of a pull, or multiple collaborators have submitted a patch in a single pull (idk if that's possible right now).

To make it simpler and intuitive in the future, we could add a field in the pull settings to select co-authors.

For now, I'll get started with the initial implementation and raise some pulls for this.