fix: readme typo

[cyril-marpaud]

No description provided.

[ejpcmac]

praise: Oh, nice catch! It seems typos did not find it, so I have reported it.

nitpick: The commit subject should be docs(readme): fix a typo, because from the description of the fix type, a fix commit “patches a code bug”. This is not the case here, as this commit updates some documentation (docs), and more specifically applies to the README.md, which has its own readme scope.

Did you use git z commit to build the commit message?

I know that it sometimes may not be obvious which type or scope to use in which case, and I really want to get some feedback on this. I have open #31 to enhance a bit the default descriptions to make them clearer. Basically, feat, sec, fix, perf and refactor should only be used when there is actually some code change involved from a user perspective.

Maybe a question like “Did you update the source code” filtering some types would help?

Also, when I’ll add the commit checker, I should find a way not only to ensure the format is correct, but also that some common type or scope errors are detected. For instance, a fix commit not touching to any file in src could be considered invalid, and would produce a friendly error message as rustc or clippy does, with a suggestion.

[cyril-marpaud]

Thank you for nitpicking, I needed that.
I did not use git-z to build that commit message initially (Booo!).
This is now fixed (right ?), very neat tool btw 👌 !

The descriptions are very clear, I just had to pay attention 😶

a fix commit not touching to any file in src could be considered invalid

For Rust projects, ofc. But ain't git-z designed for a broader audience ?

[ejpcmac]

Thanks for fixing the commit title ❤️

I’m not sure I’d have nitpicked this hard on another project for that a tiny change, but git-z is self-hosted so I thought it made sense.

a fix commit not touching to any file in src could be considered invalid

For Rust projects, ofc. But ain't git-z designed for a broader audience ?

Yes, indeed, src was just an example. It would be configurable per project. Like, both types and scopes could have a list of acceptable paths. We could even filter out invalid types / paths in the wizard based on the change. I have just created #34 for this purpose.

I want git-z to make people who don’t care about correctness actually write good Git logs effortlessly—and help people who do care as a much wanted side effect 🙂.

[cyril-marpaud]

My pleasure. I totally get it, hate it when "outsiders" f*ck up my clean log. Plus git-z is specifically designed to that end.