feat(gix): support diff.ignoreSubmodules overrides in status

[davidkna]

This PR adds support for diff.ignoreSubmodules overrides in status. As far as I can tell from experimentation this setting takes priority over submodules.<name>.ignore settings.

I decided not to change submodule::ignore because git also only applies this setting to status/diff and not submodule-specific command. Thus I opted to include it in the AsConfigured handling.

I have built starship with the changes from this PR with the changes from this PR for testing and it appears to work as expected. I would have liked to add a test, but making changes to the config_snapshot for testing appeared to be non-trivial, so I opted to omit that from this PR. I am also not sure if the DiffSubmoduleIgnoreConfig enum variant I added is the preferred way to handle errors in this case.

Related: starship/starship#6840

[Byron]

Thanks a lot for tackling this!

I think it's fair to put it there and if it's a problem for anyone, it's still possible to reconfigure the repository configuration in-memory.

I will be pushing some changes in the course of the day and hope it will be merged today as well.

[EliahKagan]

@Byron This is part of the changes in the refactoring commit 36cdd6c. This makes unconditional use of the repo field. That field is not always present:

gitoxide/gix/src/status/index_worktree.rs

Lines 198 to 199 in 36cdd6c

	#[cfg(feature = "parallel")]
	repo: crate::ThreadSafeRepository,

This causes all the currently observed CI failures. For example, in test, when it runs cargo check --no-default-features --features small, it fails with:

    Checking gix v0.73.0 (/home/runner/work/gitoxide/gitoxide/gix)
error[E0609]: no field `repo` on type `&mut BuiltinSubmoduleStatus`
   --> gix/src/status/index_worktree.rs:289:45
    |
289 |                         .with_leniency(self.repo.config.lenient_config)?;
    |                                             ^^^^ unknown field
    |
    = note: available fields are: `mode`, `git_dir`, `submodule_paths`

For more information about this error, try `rustc --explain E0609`.
error: could not compile `gix` (lib) due to 1 previous error
error: Recipe `check` failed on line 46 with exit code 101

I don't know how this is best fixed, but I figured I'd mention it, since it looks from #2107 (comment) like this may not have been anticipated.

---

Once that is fixed, I would expect everything to pass, other than the lint failure seen before in 6693ab9. That lint failure is unrealted to any of the changes made in this PR. Clippy in Rust 1.89 detects something in gix-packetline that is considered dead code, causing the lint job to fail. This is fixed in #2108, so rebasing the feature branch here onto main should fix it for this PR (as in #2106).

[Byron]

That was quite an oversight. The fix was simple, but also shows another issue with the current implementation: without parallel in-memory overrides can't be respected. Trying to use a ThreadSafeRepository unconditionally fails as it actually isn't thread-safe without the parallel feature.

This is certainly something to address as it definitely is surprising at best, and a straight lie at worst.
To address it, one basically has to enable parallel all the time, which also goes against the idea that single-threaded implementations shouldn't have to pay for atomics and locks if they don't need them.
Ultimately, I just lived with the shortcoming and accepted that reality by adjusting the test expectations.

[Byron]

On another note, I don't think there necessarily is any value from that parallel feature, as I don't know of anyone who clearly benefits from not setting it. So maybe at some point, it really should just go away.