From ee128898d9d8daa1168c06a2d13266d41903099e Mon Sep 17 00:00:00 2001 From: NAHO <90870942+trueNAHO@users.noreply.github.com> Date: Wed, 27 Aug 2025 00:42:43 +0200 Subject: [PATCH] doc/src/commit_convention: consistently indicate root directories Fixes: 57d036d92283 ("doc: commit_convention: overhaul and formalize unspoken rules (#1717)") --- doc/src/commit_convention.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/commit_convention.md b/doc/src/commit_convention.md index 506d6d4e..11b22dd0 100644 --- a/doc/src/commit_convention.md +++ b/doc/src/commit_convention.md @@ -21,7 +21,7 @@ where | Element | Description | |-----------------------|-------------| -| `«SUBSYSTEM»` | Area of patched files, optionally nested using `:` for general subsystems and `/` for paths.

For example, a patch to `/stylix/hm/` should be formatted as `stylix/hm` instead of `stylix: hm`, while `/stylix/*/palette.nix` should be formatted as `stylix: palette`.

Specific conventions include simplifying `modules/«MODULE»` to `«MODULE»`, mapping `/flake.{lock,nix}` and `/flake/` to `flake`, mapping `/.github/` to `ci`, and using `treewide` for changes that cannot be categorized under a more specific subsystem. | +| `«SUBSYSTEM»` | Area of patched files, optionally nested using `:` for general subsystems and `/` for paths.

For example, a patch to `/stylix/hm/` should be formatted as `stylix/hm` instead of `stylix: hm`, while `/stylix/*/palette.nix` should be formatted as `stylix: palette`.

Specific conventions include simplifying `/modules/«MODULE»` to `«MODULE»`, mapping `/flake.{lock,nix}` and `/flake/` to `flake`, mapping `/.github/` to `ci`, and using `treewide` for changes that cannot be categorized under a more specific subsystem. | | `«SUMMARY»` | Concise, single-line explanation of up to 72 characters, written in the imperative mood, starting lowercase, and not ending with punctuation. | | `«BODY»` | Detailed, self-contained explanation of the problem, its user impact, the technical solution, and any optimizations or trade-offs, focusing on one problem per patch. | | `«BREAKING_CHANGE»` | Dedicated `BREAKING CHANGE: «BODY»` section for breaking changes. |