`package` includes untracked files when run from workspace member

[john-h-kastner-aws]

Problem

When running cargo package in a workspace member crate, I expect to see an error if there are any untracked files, but I do not.

Steps

#!/bin/bash -x
mkdir pkg-bug-demo
(
  cd pkg-bug-demo
  git init
  printf '[workspace]\nresolver = "3"' > Cargo.toml
  cargo new inner
  git add .
  git commit -m 'init'
  touch inner/untracked
  cargo package --list # prints error as expected
  cd inner
  cargo package --list # no error, with `untracked` included in list of files
)
rm -rf pkg-bug-demo

output is

+ mkdir pkg-bug-demo
+ cd pkg-bug-demo
+ git init
Initialized empty Git repository in /home/jkastner/pkg-bug-demo/.git/
+ printf '[workspace]\nresolver = "3"'
+ cargo new inner
    Creating binary (application) `inner` package
      Adding `inner` as member of workspace at `/home/jkastner/pkg-bug-demo`
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
+ git add .
+ git commit -m init
[main (root-commit) 14b4ff9] init
 3 files changed, 12 insertions(+)
 create mode 100644 Cargo.toml
 create mode 100644 inner/Cargo.toml
 create mode 100644 inner/src/main.rs
+ touch inner/untracked
+ cargo package --list
warning: manifest has no description, license, license-file, documentation, homepage or repository
  |
  = note: see https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info
error: 1 files in the working directory contain changes that were not yet committed into git:

inner/untracked

to proceed despite this and include the uncommitted changes, pass the `--allow-dirty` flag
+ cd inner
+ cargo package --list
warning: manifest has no description, license, license-file, documentation, homepage or repository
  |
  = note: see https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info
.cargo_vcs_info.json
Cargo.lock
Cargo.toml
Cargo.toml.orig
src/main.rs
untracked
+ rm -rf pkg-bug-demo

Possible Solution(s)

I think the problem is the pathspec used here

cargo/src/cargo/ops/cargo_package/vcs.rs

Lines 287 to 291 in 6234444

	.into_iter(
	relative_package_root.map(|rela_pkg_root| {
	gix::path::into_bstr(rela_pkg_root).into_owned()
	}), /* pathspec patterns */
	)

IIUC, the working directory is the workspace member, so rela_pkg_root is interpreted relative to that path instead of the workspace/repo root. Assuming the gitx library has the same pathspec as git, it needs to be something like :/{rela_pkg_root}.

So, in terms of git status:

#!/bin/bash -x
mkdir status-demo
(
  cd status-demo
  git init
  mkdir inner
  touch inner/tracked
  git add inner
  git commit -m init
  touch inner/untracked
  cd inner
  git status # reports `untracked`, but checks status for full repo
  git status inner # what cargo is doing. trys to report status for `inner` relative to current directory 
  git status :/inner # reports status for `inner` relative to crate root
)
rm -rf status-demo

Notes

No response

Version

cargo 1.92.0 (344c4567c 2025-10-21)
release: 1.92.0
commit-hash: 344c4567c634a25837e3c3476aac08af84cf9203
commit-date: 2025-10-21
host: x86_64-unknown-linux-gnu
libgit2: 1.9.1 (sys:0.20.2 vendored)
libcurl: 8.15.0-DEV (sys:0.4.83+curl-8.15.0 vendored ssl:OpenSSL/3.5.4)
ssl: OpenSSL 3.5.4 30 Sep 2025
os: Amazon Linux AMI 2023.0.0 [64-bit]

I believe this behavior was introduce in dfe3737

[weihanglo]

Confirmed that this is a regression introduced in 1.90.0, which is likely #15534.

[weihanglo]

The fact that the old git2 pathspec implementation #14997 didn't have this bug was because libgit2 doesn't respect the current working directory and always use the repostitory root, if I understand correctly:

https://github.com/libgit2/libgit2/blob/3ac4c0adb1064bad16a7f980d87e7261753fd07e/src/libgit2/pathspec.c#L111

So that was a coincidence it wasn't buggy.