From 5f84c73b5ab3f694f9e001f621bfd6d1c3572bc2 Mon Sep 17 00:00:00 2001 From: Philip Metzger Date: Wed, 28 Aug 2024 18:22:37 +0200 Subject: [PATCH] RFC: Formalize our commit style to mention that we don't use conventional commits. It's the simple _when in Rome, do as the Romans do_ rule. --- docs/contributing.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/docs/contributing.md b/docs/contributing.md index 53bc315c46..cc6b5e00dd 100644 --- a/docs/contributing.md +++ b/docs/contributing.md @@ -36,9 +36,17 @@ commit and the new feature in a different commit. If the refactoring itself consists of many parts, try to separate out those into separate commits. You can use `jj split` to do it if you didn't realize ahead of time how it should be split up. Include tests and documentation in the same commit as the code they -test and document. The commit message should describe the changes in the commit; +test and document. + +The commit message should describe the changes in the commit; the PR description can even be empty, but feel free to include a personal -message. +message. We write commit messages in an affected component style and don't use +[conventional commits](www.conventionalcommits.org/en/v1.0.0/). This means if +you modified a command in the CLI, use its name as the topic, e.g +`next/prev: ` or `conflicts: `. We don't +currently have a specific guidelines on what to write in the topic field, but +the reviewers will help you provide a topic if you have difficulties choosing +it. When you address comments on a PR, don't make the changes in a commit on top (as is typical on GitHub). Instead, please make the changes in the appropriate