Skip to content

refactor(args): centralize include-path resolution after repo discovery#1379

Open
o1x3 wants to merge 1 commit intoorhun:mainfrom
o1x3:refactor/centralize-include-path-resolution
Open

refactor(args): centralize include-path resolution after repo discovery#1379
o1x3 wants to merge 1 commit intoorhun:mainfrom
o1x3:refactor/centralize-include-path-resolution

Conversation

@o1x3
Copy link

@o1x3 o1x3 commented Feb 22, 2026

Description

Extracts path resolution for --workdir and --include-path into a single resolve_include_paths function that runs after repo discovery, where the repo root is available.

Previously, the workdir block set args.include_path to a raw workdir path before repo discovery (absolute or cwd-relative), which never matched the repo-relative paths from git2's diff API. This broke --workdir in v2.11.0.

The new function handles three cases:

  • Config/CLI include paths are normalized to repo-relative (strips absolute repo root prefix)
  • --workdir set to a subdirectory adds a repo-relative glob; workdir at root means no filter
  • Implicit cwd scoping when running from a subdirectory (existing behavior, preserved)

All paths (root, cwd, workdir) are canonicalized before comparison to handle symlinks.

Motivation and Context

Fixes #1369

As discussed in the issue, the path resolution logic was scattered across three locations in lib.rs. @orhun asked for a proper refactor rather than a band-aid fix.

How Has This Been Tested?

  • 9 unit tests for resolve_include_paths covering: workdir at root, workdir subdirectory, workdir outside repo, implicit cwd scoping, no scoping at root, repository arg suppressing implicit scoping, config patterns combined with workdir
  • 2 unit tests for normalize_to_repo_relative
  • New fixture test test-workdir-root (--workdir . with empty + file-changing commits)
  • Manual verification of all scenarios from the issue repro script
  • cargo clippy --tests -- -D warnings
  • cargo +nightly fmt --all -- --check

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

Extract `resolve_include_paths` to handle workdir, cwd, and config
include paths in one place, after the repository root is known. This
fixes --workdir producing empty output since v2.11.0 (orhun#1369).

The previous logic set include_path in the workdir block before repo
discovery, producing patterns that were absolute or cwd-relative
instead of repo-relative. These never matched the repo-relative paths
from git2's diff API.

All three paths (root, cwd, workdir) are now canonicalized before
comparison, fixing symlink edge cases on macOS.
@o1x3
Copy link
Author

o1x3 commented Feb 22, 2026

hey @orhun @ognis1205 - draft is up for the refactor we discussed in #1369. main change is pulling the include-path resolution into one function that runs after repo discovery instead of the three scattered spots. still a draft so happy to rework anything based on feedback.

@codecov-commenter
Copy link

Codecov Report

❌ Patch coverage is 64.86486% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 48.18%. Comparing base (3f29492) to head (be7da48).

Files with missing lines Patch % Lines
git-cliff/src/lib.rs 64.87% 13 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1379      +/-   ##
==========================================
+ Coverage   47.53%   48.18%   +0.66%     
==========================================
  Files          24       24              
  Lines        2119     2140      +21     
==========================================
+ Hits         1007     1031      +24     
+ Misses       1112     1109       -3     
Flag Coverage Δ
unit-tests 48.18% <64.87%> (+0.66%) ⬆️

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 orhun requested a review from ognis1205 February 23, 2026 11:11
@o1x3 o1x3 marked this pull request as ready for review February 24, 2026 06:47
@o1x3 o1x3 requested a review from orhun as a code owner February 24, 2026 06:47
Copy link
Collaborator

@ognis1205 ognis1205 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the effort!

I'm quite cautious about this PR, especially around the directory handling changes.

Historically, this area has been fragile: fixing one bug has often led to unexpected behavior elsewhere, and we've gone back and forth with multiple fixes. Because of that history, I'm very hesitant to introduce substantial changes now.

On top of that, I believe the git-cliff crate as a whole needs a broader refactoring. Although this PR is labeled as a refactoring, I feel it also contains unclear functional changes, and I'm not convinced this is the right time for such a refactoring.

In particular, simply consolidating directory handling into a single function doesn't address the root issues. Given the past instability, I'm concerned we'll reintroduce bugs that we haven't fully anticipated.

Personally, I'd prefer to avoid major changes to the existing implementation for now, and instead fix the workdir issue based on the current code. I think that would let us isolate the problem more cleanly and reduce the risk of regressions.

cc: @orhun any thoughts on this?

Comment on lines +332 to +333
let canonical_root = fs::canonicalize(&root).unwrap_or(root);
let canonical_cwd = fs::canonicalize(&cwd).unwrap_or(cwd);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the use of unwrap on fs::canonicalize:

According to the documentation:

https://doc.rust-lang.org/std/fs/fn.canonicalize.html#errors

fs::canonicalize can fail in several common cases, such as when the path does not exist or a non-final component is not a directory. Propagating the error instead of using unwrap would allow us to inform the user about what went wrong.

let canonical_workdir = args
.workdir
.as_ref()
.map(|w| fs::canonicalize(w).unwrap_or(w.clone()));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +230 to +234
if pattern_path.is_absolute() {
if let Ok(stripped) = pattern_path.strip_prefix(canonical_root) {
return Ok(Pattern::new(stripped.to_string_lossy().as_ref())?);
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a new feature? I believe this absolute path handling should not be part of this PR's scope. The previous implementation didn't have special handling for absolute paths.
If we want to add this behavior, it should be done in a separate PR with proper tests and documentation.

patterns.push(Pattern::new(glob.to_string_lossy().as_ref())?);
}
}
} else if patterns.is_empty() &&
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this patterns.is_empty() condition is necessary here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Setting --workdir results in an empty output

3 participants