Git-Cliff 配置检测逻辑的优化建议

Git-Cliff 是一个优秀的 Git 提交日志生成工具，它能够根据项目提交历史自动生成美观的变更日志。在实际使用中，我发现了一个关于配置检测逻辑的小问题，值得与社区分享。

问题背景

在 Rust 项目中使用 Git-Cliff 时，我尝试将配置信息放在 Cargo.toml 文件的 workspace.metadata 部分。这是一种常见的做法，可以避免在项目根目录下创建额外的配置文件。然而，Git-Cliff 2.1.2 版本似乎没有检测到这个配置位置，而是直接回退到默认配置。

技术分析

Git-Cliff 目前默认会查找以下位置的配置文件：

1. 用户指定的配置文件路径
2. 项目根目录下的 cliff.toml 文件
3. 默认内置配置

对于 Rust 项目，Cargo.toml 是一个标准的配置文件位置，许多工具（如 cargo-make、cargo-release 等）都支持从 Cargo.toml 的 [workspace.metadata] 或 [package.metadata] 部分读取配置。这种设计有以下优势：

1. 减少项目根目录下的配置文件数量
2. 保持配置与项目元数据的集中管理
3. 便于版本控制和管理

改进建议

Git-Cliff 可以扩展其配置检测逻辑，增加对 Cargo.toml 文件的检查。具体来说，可以按照以下顺序查找配置：

1. 用户通过命令行参数指定的配置文件
2. 项目根目录下的 cliff.toml
3. Cargo.toml 中的 [workspace.metadata.git-cliff] 部分
4. Cargo.toml 中的 [package.metadata.git-cliff] 部分
5. 默认内置配置

这种改进不仅符合 Rust 项目的惯例，也能提升工具的用户体验。对于多 crate 的工作区项目尤其有用，因为可以在 workspace 级别统一管理 Git-Cliff 配置。

实现考虑

在实现上需要注意以下几点：

1. 解析 Cargo.toml 时需要正确处理 TOML 格式
2. 需要考虑嵌套配置的结构，确保与独立配置文件的结构一致
3. 需要处理 workspace 和 package 配置的优先级问题
4. 需要提供清晰的日志输出，告知用户最终使用了哪个配置来源

这种改进已经在 Git-Cliff 的某个 PR 中实现，建议用户升级到包含此改进的版本。

总结

工具配置的灵活性对于开发者体验至关重要。支持从 Cargo.toml 读取配置不仅符合 Rust 生态的惯例，也能帮助开发者保持项目的整洁性。希望 Git-Cliff 能持续优化这类细节，为 Rust 开发者提供更流畅的使用体验。