fix: guard include path when running outside repo

[KindDragon]

Description

• add relative_subdirectory_path helper and unit tests to guard the monorepo auto-include logic
• only append an include_path glob when the current working directory is inside the repository root
• keep existing behaviour for callers launched from a subdirectory while avoiding ../…/**/* matches that hide every commit

Motivation and Context

Fixes #1248 — running git-cliff from a workspace root (e.g. Android’s repo checkout) started returning an empty changelog
in v2.8 because the inferred include glob pointed outside the repo. This change retains the improvement for monorepos without
breaking that workflow.

How Has This Been Tested?

• cargo test
• cargo run --bin git-cliff -- --config ../cliff.toml --repository ../android-sim -- sh/25.2.12..sh/25.3.0

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.

[welcome]

Thanks for opening this pull request! Please check out our contributing guidelines! ⛰️

[codecov-commenter]

Codecov Report

❌ Patch coverage is 50.00000% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 43.66%. Comparing base (ee9f742) to head (9403a0e).

Files with missing lines	Patch %	Lines
git-cliff/src/lib.rs	50.00%	7 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1269      +/-   ##
==========================================
+ Coverage   43.55%   43.66%   +0.11%     
==========================================
  Files          22       22              
  Lines        1984     1993       +9     
==========================================
+ Hits          864      870       +6     
- Misses       1120     1123       +3     

Flag	Coverage Δ
unit-tests	43.66% <50.00%> (+0.11%)	⬆️

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.

[KindDragon]

I don't have much experience in Rust. Feel free to edit/close it if it require a lot of work

[orhun]

cc @ognis1205 can you take a look?

[ognis1205]

My impression is that this functionality depends quite a lot on the repository structure and the execution context (e.g. working directory), so I was aiming for a more comprehensive and loggable implementation.

At the sketch level, I was thinking of something like:

pub enum RepositoryType {
    Bare,
    Worktree(PathBuf),
    Submodule(PathBuf),
    Normal,
}

pub enum WorkingDir {
    Root,
    Subdir(PathBuf),
}

pub struct Repository {
    inner: GitRepository,
    path: PathBuf,
    changed_files_cache_path: PathBuf,
    pub repository_type: RepositoryType,
    pub is_git_symlink: bool,
}

With such enums/structs living in appropriate modules of git-cliff / git-cliff-core, the calculation of include_path could be handled via a switch over repository_type / working_dir / is_git_symlink, with proper logging in each case.

The approach taken in this PR looks valid for the targeted issue, but from an operational and long-term maintenance perspective, I feel we might want a more robust design.

Given that, I see three possible ways forward:

• Review and merge this PR as-is as a bugfix for #1248 only, and handle the broader tracking issue in a separate PR.
• Move toward the more maintainable design outlined above (in this PR).
• Take over this PR (with a new working branch) and submit a co-authored PR with the extended design.

(cc: @orhun — what do you think about the direction of the above approach?)

[ognis1205]

@KindDragon @orhun

What do you think about this perspective?
If my implementation idea is not clear, I’m happy to open a separate PR to illustrate it more concretely. Personally, I would like development to proceed in a way that keeps the original author credit of this PR intact.

[orhun]

Hey @ognis1205, sorry for the delay.

Sure, that sounds reasonable. I also agree that a more robust solution would be better here (but I guess this is a good short-term solution).

The proposed sketch above also makes sense to me.

[orhun]

Sorry for the delay. The changes look good, just needs some refactoring.

@KindDragon interested in addressing the changes? 🙂
If not, me or @ognis1205 can also take over and finish this up.

[orhun]

I don't like placing everything inside lib.rs (anymore) so please split out the changes into a separate module, preferably util.rs or path.rs

[orhun]

This needs a short comment explaining the behavior.

[orhun]

The tests should be named more properly. Maybe use the name of the module as a prefix (path_detects_* or util_detects_*, etc.)

[ognis1205]

Hey @ognis1205, sorry for the delay.

Sure, that sounds reasonable. I also agree that a more robust solution would be better here (but I guess this is a good short-term solution).

The proposed sketch above also makes sense to me.

Thanks for your reply! Glad to hear the sketch makes sense.

[KindDragon]

Please feel free make changes what your need. I just want it to fix my issue in some way and don't have much experience in rust or you project

[ognis1205]

@KindDragon Thanks for your work on this!
I’ll take over and update this PR to properly address the issue, and I’ll make sure you stay listed as a co-author.

[ognis1205]

I will work on this soon.