fix: handling of nested annotated tags

[GChernikov]

Fix handling of nested annotated tags (tags pointing to other tags instead of commits directly).

Description

When an annotated tag points to another annotated tag (instead of directly to a commit), git-cliff silently skips it. This PR fixes the issue by using obj.peel(ObjectType::Commit) to follow the entire chain of tag objects until reaching the final commit.

Motivation and Context

In some workflows, tags are "promoted" by creating new tags pointing to existing ones. For example:

v1.0.0-stable -> v1.0.0-rc (tag) -> v1.0.0-staging (tag) -> commit

The current code uses tag.target().into_commit() which only resolves one level of indirection. When the target is another tag object (not a commit), into_commit() fails and the tag is silently skipped from the changelog.

How Has This Been Tested?

Added git_nested_tags test that:

1. Creates a temp repository with an empty commit
2. Creates an annotated tag v1.0.0-staging pointing to the commit
3. Creates a nested annotated tag v1.0.0-stable pointing to v1.0.0-staging
4. Verifies that v1.0.0-stable correctly resolves to the original commit

The test fails without the fix and passes with it.

Screenshots / Logs (if applicable)

Before fix - nested tag is missing:

$ git tag -a v1.0.0-staging -m "staging"                                                                                                                                                                 
$ git tag -a v1.0.0-stable -m "stable" $(git rev-parse v1.0.0-staging)                                                                                                                                   
$ git cliff --tag-pattern ".*-stable$"                                                                                                                                                                   
# v1.0.0-stable is missing from output

After fix - nested tag is included correctly.

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 (if applicable).
• I have formatted the code with rustfmt.
  • cargo +nightly fmt --all
• I checked the lints with clippy.
  • cargo clippy --tests --verbose -- -D warnings
• I have added tests to cover my changes.
• All new and existing tests passed.
  • cargo test

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 44.17%. Comparing base (91e65f5) to head (1be28f6).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1360      +/-   ##
==========================================
+ Coverage   44.14%   44.17%   +0.03%     
==========================================
  Files          24       24              
  Lines        2286     2287       +1     
==========================================
+ Hits         1009     1010       +1     
  Misses       1277     1277              

Flag	Coverage Δ
unit-tests	44.17% <100.00%> (+0.03%)	⬆️

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]

thanks for the PR!

[orhun]

Would also love to have a test fixture for this so that we would see how this behaves in the changelog generation context.

[GChernikov]

Added a test fixture test-nested-tags that covers this scenario.

The fixture creates a 3-level nested tag chain:
v0.1.0-stable → v0.1.0-rc → v0.1.0-staging → commit

With tag_pattern = "v.*-stable$", only the nested v0.1.0-stable tag is matched. The test verifies that it correctly resolves to the underlying commit and appears in the changelog.

Without the fix, the output shows [unreleased] instead of [v0.1.0-stable] because the nested tag fails to resolve

[GChernikov]

Also updated the fixture to show this more clearly.

Now the template strips v prefix and -stable suffix, so the changelog shows clean versions:

Tags: v0.1.0-staging → v0.1.0-rc → v0.1.0-stable
Output: ## [0.1.0] - 2022-04-06

This better reflects the actual use case — promotion workflow with clean changelog output.

[GChernikov]

@orhun could you please review changes? Is there anything alse I can do to help you merge this PR?