feat(tracing): migrate logging to tracing

[ognis1205]

Description

This PR migrates the logging implementation from env_logger to tracing.

The migration preserves the existing log format while extending it to include span information, enabling more structured and contextual logging without changing the default user experience.

Motivation and Context

This change is motivated by the following discussion and issues:

• Review of log level usage: promote certain trace! logs to info! to improve observability #1191
• Migrate logging from env_logger to tracing + tracing-subscriber #1268

The goal is to modernize git-cliff's logging infrastructure by adopting tracing, while maintaining backward compatibility and avoiding unnecessary complexity in the core crate.

What Has Changed

• The logger has been updated to emit spans in a format consistent with the existing log output.
• Span instrumentation is applied only to methods that affect the changelog generator's semantics (e.g. changelog, release, and commit processing).
• git-cliff-core now depends on tracing behind a feature flag.
  • When the feature is disabled, the behavior is unchanged and only the existing log output is produced.
  • When the feature is enabled, spans are created and included in the output.
• Remote metadata progress reporting has been fully migrated to a tracing-based implementation using tracing-indicatif.
• The progress bar implementation is intentionally kept simple.
  • While richer progress reporting is possible with tracing, implementing such behavior cleanly would require API changes outside of git-cliff-core.
  • Given the current API design, this PR avoids introducing additional complexity and leaves room for future design discussions.

How Has This Been Tested?

• Existing unit tests were run.
• Logging output was verified manually.

Screenshots / Logs (if applicable)

N/A

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (no code change)
• Refactor (refactoring production code)
• Other

Checklist:

• My code follows the code style of this project.
• I have updated the documentation accordingly.
• I have formatted the code with rustfmt.
• I checked the lints with clippy.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 2.06186% with 95 lines in your changes missing coverage. Please review.
✅ Project coverage is 47.41%. Comparing base (78003e2) to head (7f6b875).

Files with missing lines	Patch %	Lines
git-cliff/src/logger.rs	0.00%	73 Missing ⚠️
git-cliff-core/src/changelog.rs	0.00%	21 Missing ⚠️
git-cliff-core/src/commit.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1308      +/-   ##
==========================================
+ Coverage   47.40%   47.41%   +0.01%     
==========================================
  Files          24       25       +1     
  Lines        2131     2135       +4     
==========================================
+ Hits         1010     1012       +2     
- Misses       1121     1123       +2     

Flag	Coverage Δ
unit-tests	47.41% <2.07%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[orhun]

10 seconds ago I was happy that my GitHub notifications were clear and then Shingo comes in with a crazy PR!!!!!

+0 additions -0 deletions though. Love it. LGTM

[orhun]

planning to do any progress on this soon? (added to 2.12.0 milestone)

[ognis1205]

planning to do any progress on this soon? (added to 2.12.0 milestone)

Yeah, I'm planning to open a PR later this week.
Does that timeline work for the 2.12.0 milestone?

[orhun]

yup, 2.12.0 will happen in 2026 :)
so we have a whole year!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[ognis1205]

Sorry for the delay. I'll start working on this PR today.

[orhun]

No worries at all!

[ognis1205]

This is ready for review now @orhun .

I consider this a first draft, and there are likely areas open for discussion. When you have time, I'd really appreciate your thoughts and feedback.

[orhun]

Would be great if we could keep the old arrow-styled progress indicator (for the first line in the logs at least)

I really like the detailed logging btw!

Let me know when this is ready for review

[ognis1205]

Would be great if we could keep the old arrow-styled progress indicator (for the first line in the logs at least)

That should be doable.

We can bring back the old arrow-style progress indicator, but when implemented on top of tracing / span-based instrumentation via tracing-indicatif, it would look slightly different from the previous approach:

If that's acceptable, I'm happy to revert the change accordingly. In addition to the progress indicator itself, we can of course also emit explicit logs at the beginning and end of the processing step.

In an ideal world, I'd like to include a progress indicator with percentages as well. However, with the current design, where spans and logging live inside the core SDK, that starts to get a bit messy from a design perspective. It's technically possible, but I intentionally avoided it for now to keep the core clean.

Let me know when this is ready for review

Regarding ANSI/ASCII color codes on Windows or non-TTY environments: since we were already using colored output before, I think it's reasonable to review this as-is for now.

If you're open to it, I'd really appreciate review feedback on the following points in the context of adding this to git-cliff-core as an SDK:

• Which functions should be annotated with #[instrument] (all vs. a subset)
• Whether span names should be explicitly set
• Which fields are appropriate to capture on spans

From a "keep git-cliff-core as a clean SDK" perspective, another option could be to explore whether progress reporting can be handled in a less hacky way on top of env_logger, if that's feasible. Just putting it out there as an alternative.

[orhun]

I like how this turned out!

Some points of discussion:

• The spinner gets red quickly I think. Wouldn't be nice to adjust the timing there?
• The main spinner messages seem developer oriented now. Previously, it was something like "fetching data from GitHub..." but now it says things like add_remote_data, get_github_metadata and so on. I know git-cliff is mostly directed at developers, but I still think that we could avoid programmatic-looking info-level messages. Wdyt?

[ognis1205]

Thanks for the feedback!

• The spinner gets red quickly I think. Wouldn't be nice to adjust the timing there?

No objections here. I agree it turns red a bit too quickly. I'll slow down the timing so the transition happens later.

• The main spinner messages seem developer oriented now. Previously, it was something like "fetching data from GitHub..." but now it says things like add_remote_data, get_github_metadata and so on. I know git-cliff is mostly directed at developers, but I still think that we could avoid programmatic-looking info-level messages. Wdyt?

There is actually a reason for the current behavior. Since I implemented using tracing-indicatif, most of the macros ended up being defined in the git-cliff-core side. Because that crate also has an SDK role, I intentionally avoided defining end-user-facing messages there and instead exposed the function names directly.

That said, I don't have any objection to making the messages more human-readable. In the future, when we have a chance to refactor, I'd like to explore the idea of making git-cliff-core more "log-less" and keeping user-facing messaging closer to the CLI layer.

For now, I agree with your point and will update the messages to be more readable.

[ognis1205]

• The spinner gets red quickly I think. Wouldn't be nice to adjust the timing there?

No objections here. I agree it turns red a bit too quickly. I'll slow down the timing so the transition happens later.

Updated the timing so that the transition now occurs after 32 seconds (8 seconds previously), making the progress display less abrupt.

• The main spinner messages seem developer oriented now. Previously, it was something like "fetching data from GitHub..." but now it says things like add_remote_data, get_github_metadata and so on. I know git-cliff is mostly directed at developers, but I still think that we could avoid programmatic-looking info-level messages. Wdyt?

There is actually a reason for the current behavior. Since I implemented using tracing-indicatif, most of the macros ended up being defined in the git-cliff-core side. Because that crate also has an SDK role, I intentionally avoided defining end-user-facing messages there and instead exposed the function names directly.

That said, I don't have any objection to making the messages more human-readable. In the future, when we have a chance to refactor, I'd like to explore the idea of making git-cliff-core more "log-less" and keeping user-facing messaging closer to the CLI layer.

For now, I agree with your point and will update the messages to be more readable.

Implemented a macro to output non-developer friendly progress messages in tracing spans.
Previously, messages were developer-oriented. Now, the macro allows progress updates to display user-friendly text while still working with the tracing-indicatif integration.