Copy excluding .gitignore files causes failure without --in-place

[ASuciuX]

Hello @sourcefrog, hope you’re doing well!

I’ve seen some great updates since I last implemented cargo-mutants in different workflows.

I ran into an issue where cargo-mutants fails when working with a copied version of the project. The error appears to be a binding issue—multiple dependencies rely on the same library but with different versions, causing cargo build to be unable to resolve them correctly. However, using the --in-place flag works fine.

I haven’t fully investigated the root cause or a potential underlying solution, but I found that using --in-place is preferable for CI regardless. The main concern is that, locally, running cargo-mutants requires a cloned version of the repository, which isn’t ideal. Given this, I wanted to open this issue and share my findings, especially since I noticed specified in the documentation to also share cases like this.

Here’s the failing CI action log when running cargo-mutants without --in-place:
https://github.com/hirosystems/ordhook/actions/runs/13164203008/job/36740241226#step:9:986

And here’s a related discussion on the dependency issue:
hirosystems/ordhook#395

[sourcefrog]

Hi @ASuciuX

This sounds like #117 but I guess you are already using >25.0.0 that includes that fix?

If you can narrow this down to a specific failure that will help.

Some things to try:

1. If you manually copy the tree with cp -r does it work?
2. If you manually copy the tree and then delete target does it work?

[ASuciuX]

Yes, I am using 25.0.0.

1. The copy containing the target still fails without --in-place. and works with --in-place`.
2. Same

I've copied the codebase to a random user location. Should I copy it to a temp root location?

[sourcefrog]

I haven’t fully investigated the root cause or a potential underlying solution, but I found that using --in-place is preferable for CI regardless.

Separately from this bug: yes, that is better for CI. There's no point spending time copying to a temp directory if the source is itself a disposable temp directory.

[sourcefrog]

• The copy containing the target still fails without --in-place and works with --in-place.

Interesting. If it's not the copying then I guess the problem is with the manifest and cargo config fixups done in https://github.com/sourcefrog/cargo-mutants/blob/main/src/manifest.rs after the copy.

cargo-mutants/src/build_dir.rs

Lines 55 to 77 in 8c9f648

	pub fn copy_from(source: &Utf8Path, options: &Options, console: &Console) -> Result<BuildDir> {
	let name_base = format!("cargo-mutants-{}-", source.file_name().unwrap_or("unnamed"));
	let source_abs = source
	.canonicalize_utf8()
	.context("canonicalize source path")?;
	let temp_dir = copy_tree(source, &name_base, options, console)?;
	let path: Utf8PathBuf = temp_dir
	.path()
	.to_owned()
	.try_into()
	.context("tempdir path to UTF-8")?;
	fix_manifest(&path.join("Cargo.toml"), &source_abs)?;
	fix_cargo_config(&path, &source_abs)?;
	let temp_dir = if options.leak_dirs {
	let _ = temp_dir.into_path();
	info!(?path, "Build directory will be leaked for inspection");
	None
	} else {
	Some(temp_dir)
	};
	let build_dir = BuildDir { path, temp_dir };
	Ok(build_dir)
	}

A good next step would be to find the specific failing cargo command and its output.

[sourcefrog]

OK the failure is pretty apparent in https://github.com/hirosystems/ordhook/actions/runs/13164203008/job/36740241226#step:9:986,

--> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/p256k1-7.2.2/src/_rename.rs:10:5
error[E0432]: unresolved imports crate::bindings::s2bca0a5cbf756dd4ff1f0bda4585a7d3c64e1480_secp256k1_context_preallocated_clone, crate::bindings::s2bca0a5cbf756dd4ff1f0bda4585a7d3c64e1480_secp256k1_context_preallocated_clone_size, crate::bindings::s2bca0a5cbf756dd4ff1f0bda4585a7d3c64e1480_secp256k1_context_preallocated_create, crate::bindings::s2bca0a5cbf756dd4ff1f0bda4585a7d3c64e1480_secp256k1_context_preallocated_destroy, crate::bindings::s2bca0a5cbf756dd4ff1f0bda4585a7d3c64e1480_secp256k1_context_preallocated_size

These names come from https://github.com/Trust-Machines/p256k1/blob/master/p256k1/src/bindings.rs

I notice that in this tree, src/bindings.rs is both checked in, and also in .gitignore. By default cargo-mutants skips gitignored files, so that might be what's breaking it.

I would try with --gitignore=false and that will probably fix it? At least, let me know?

https://github.com/Trust-Machines/p256k1 itself seems to run OK under mutants, although finding some gaps.

[sourcefrog]

#454 says we perhaps shouldn't skip gitignored files by default, because it saves a bit of time copying but might cause confusing errors when the tree depends on gitignored files. Maybe this is more evidence for it.

[ASuciuX]

Nice, thank you! It works with --gitignore=false. Indeed it was because of that bindings.

How does it skip the gitignored files? Doesn’t it copy them to the temporary runs after building the project?

[sourcefrog]

With --gitignore=true (currently the default) it just does not copy them into the temp dirs:

cargo-mutants/src/copy_tree.rs

Lines 46 to 60 in debd7cb

	let mut walk_builder = WalkBuilder::new(from_path);
	let copy_vcs = options.copy_vcs; // for lifetime
	walk_builder
	.git_ignore(options.gitignore)
	.git_exclude(options.gitignore)
	.git_global(options.gitignore)
	.hidden(false) // copy hidden files
	.ignore(false) // don't use .ignore
	.require_git(true) // stop at git root; only read gitignore files inside git trees
	.filter_entry(move |entry| {
	let name = entry.file_name().to_string_lossy();
	name != "mutants.out"
	&& name != "mutants.out.old"
	&& (copy_vcs || !VCS_DIRS.contains(&name.as_ref()))
	});

[ASuciuX]

Thank you