Bump the cargo group across 1 directory with 68 updates

[dependabot]

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[EliahKagan]

LGTM. This supersedes #2068 due to #2069. All tests are passing.

---

The updated version of prodash includes a fix for GitoxideLabs/prodash#39. This was considered a breaking change in prodash because users could potentially be relying on the old logging behavior. prodash is a direct dependency here, and it is exposed with a pub use:

gitoxide/gix-features/src/progress.rs

Lines 6 to 14 in 9accfba

	pub use prodash::{
	self,
	messages::MessageLevel,
	progress::{
	AtomicStep, Discard, DoOrDiscard, Either, Id, Step, StepShared, Task, ThroughputOnDrop, Value, UNKNOWN,
	},
	unit, BoxedDynNestedProgress, Count, DynNestedProgress, DynNestedProgressToNestedProgress, NestedProgress,
	Progress, Unit,
	};

But I'm not sure that necessarily means bumping it is a breaking change here, nor even necessarily that it is a change that users are especially interested in. All uses that compiled before still do. Maybe it should go into the changelog here but not as a breaking change? In any case, it seems to me that it is okay to merge this and then figure out if anything special has to be done to improve any changelogs.

[Byron]

The updated version of prodash includes a fix for GitoxideLabs/prodash#39. This was considered a breaking change in prodash because users could potentially be relying on the old logging behavior. prodash is a direct dependency here, and it is exposed with a pub use:

That's a great catch! We didn't expose anything related to it, but in theory there was a log-renderer that now wouldn't be available unless that feature is explicitly enabled.

I also checked and noticed that gix-features wouldn't naturally (or already) be indicating a breaking change, so it would be possible to cause some sort of breakage in the next release.
However, as prodash doesn't seem to be exposed directly, people wouldn't be able to do gix_features::prodash::log_renderer, so probably it's still not a breaking change.

So, all good. And even if it isn't, I think the number of affected users here would be very small.

[EliahKagan]

However, as prodash doesn't seem to be exposed directly, people wouldn't be able to do gix_features::prodash::log_renderer, so probably it's still not a breaking change.

I think prodash itself is exposed directly if the progress feature is enabled. But I don't see a difference between what is made available to access in gix_features::progress::prodash before and after the change.

I did not think to check that before, and I am not certain I am checking it correctly now. One way I have checked it is by seeing what tab-completes in evcxr:

ek in 🌐 catenary in ~
❯ evcxr
Welcome to evcxr. For help, type :help
>> :dep gix-features = { version = "0.42.1", features = ["progress"] }
   Compiling libc v0.2.174
   Compiling autocfg v1.5.0
   Compiling parking_lot_core v0.9.11
   Compiling scopeguard v1.2.0
   Compiling smallvec v1.15.1
   Compiling log v0.4.27
   Compiling lock_api v0.4.13
   Compiling parking_lot v0.12.4
   Compiling prodash v29.0.2
>> gix_features::progress::prodash::
BoxedDynNestedProgress             Root                               render
BoxedProgress                      Throughput                         throughput
Count                              Unit                               traits
DynNestedProgress                  WeakRoot                           tree
DynNestedProgressToNestedProgress  info!()                            unit
NestedProgress                     messages                           warn!()
Progress                           progress

❯ evcxr
Welcome to evcxr. For help, type :help
>> :dep gix-features = { git = "https://github.com/GitoxideLabs/gitoxide.git", features = ["progress"] }
   Compiling autocfg v1.5.0
   Compiling libc v0.2.174
   Compiling parking_lot_core v0.9.11
   Compiling smallvec v1.15.1
   Compiling scopeguard v1.2.0
   Compiling lock_api v0.4.13
   Compiling parking_lot v0.12.4
   Compiling prodash v30.0.1
>> gix_features::progress::prodash::
BoxedDynNestedProgress             Root                               progress
BoxedProgress                      Throughput                         render
Count                              Unit                               throughput
DynNestedProgress                  WeakRoot                           traits
DynNestedProgressToNestedProgress  info!()                            tree
NestedProgress                     log                                unit
Progress                           messages                           warn!()

I think the result of tab-completion in evcxr shows everything public as well as sometimes some things that are not public. In this case, with the upgraded prodash, an new module, log, is shown. (It is not public, but it is shown.) Everything else appears the same.

[Byron]

I checked again and there is only the Log type gated behind that default feature, which isn't anything we re-export.
All should be OK in this case.