Add --quiet flag

[ajiho]

Is there an existing issue or pull request for this?

• I have searched the existing issues and pull requests

Feature description

For projects that integrate git-cliff midway, the console can produce a lot of warnings. I’m not sure if there’s already an option to address this—if there is, feel free to disregard this.

Desired solution

As mentioned above

Alternatives considered

no

Additional context

No response

[orhun]

Hmm, maybe we could add a --quiet option in contrast to --verbose.

You can disable logging via unsetting the RUST_LOG environment variable.

[lud-wj]

You could log if it is not filtered ?

I have some commits fully in parenthesis like (typo) or (cliff) or (changelog) for stuff that does not impact really the project or the docs and is purely dev centric. I'd really like not to have warnings for those.

I added RUST_LOG=0 in my env but I wonder if that can impact other programs installed with cargo install.

[ognis1205]

Hi all,

Regarding this issue, the root cause is likely the changes I introduced in PR #1244, where commits that do not follow the conventional commit specification were being logged as WARN.

This is because git-cliff is designed to work based on conventional commits, so the WARN was intended to notify users about commits that do not match the expected format.

For this issue, I see a few possible approaches:

1. Implement a --quiet flag to suppress logs entirely.
2. Revert the log level from WARN to TRACE.
3. Revert the log level to TRACE but still output a single WARN summarizing the number of commits that did not match the conventional commit format (like statistics).

I apologize for any inconvenience this may have caused and appreciate any feedback on the preferred approach.

[lud-wj]

@ognis1205 It's not as bad, it just adds some noise but it's not breaking anything.

A flag in the config to not emit a WARN could be possible? Otherwise option 3 seems fine indeed.

[ognis1205]

@ognis1205 It's not as bad, it just adds some noise but it's not breaking anything.

A flag in the config to not emit a WARN could be possible? Otherwise option 3 seems fine indeed.

Technically, adding a config property to suppress these warnings could be possible, but it might break the semantics of log levels, so I'd personally lean toward avoiding that if we can.

If we were to explore this, a flag/property with a clearly scoped name, e.g., --suppress-conventional-commit-warning / suppress-conventional-commit-warning, seems safer than a global --quiet / quiet, even though it's a bit long.

That said, I'm open to other perspectives. Personally, I don't think a flag is the ideal solution for the reasons above, and while using RUST_LOG with a target could be an option, I don't have a concrete idea yet.

For now, I'd still recommend approach 2 or 3, but it would be great to hear more suggestions from others.

[ognis1205]

Following up on this discussion, I've opened a PR related to this:

#1355

If anyone is interested, I'd really appreciate any feedback or suggestions! Thanks!

[deadnews]

I think this could be the default behavior as it was before the last version.

These warnings could be behind the verbose flags (-v/-vv/-vvv).

There's nothing I can do about old commit messages from many years ago.
Displaying warnings for every old commit on each utility call adds unnecessary noise.
Alternatively, warnings could be limited to recent commits.

[shfx]

Yeah this should be the default. It's weird that we suddenly have to deal with warnings regarding some old commits. We can't change them in anyway without rewriting history. IMHO there should be no warnings unless you configure cliff to throw or to be more verbose.