Bump the cargo group with 69 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]

The CI failures are due to the need to adapt to breaking changes in imara-diff as of version 0.2.0. Once either that is fixed or imara-diff is temporarily held back, this PR may or may not be ready, I'm not sure.

This version of imara-diff has not yet had a changelog or release notes entry anywhere that I have found. pascalkuthe/imara-diff#27 suggests that others have not found it either, so maybe there isn't one (or not yet). I did glance at the changes last month in the imara-diff commit history, and it looked like it should be feasible to adapt gitoxide's use of imara-diff to the changed interface. But I did not, and still have not, worked on that or figured out quite how it should be done. As for possible relevant behavioral changes, I haven't investigated that at all.

In view of the substantial number of other things I'm working on in gitoxide and otherwise, taken together with the likelihood that more things of higher priority than this in gitoxide will arise in the meantime (such as #1890-like failures on GNU/Linux x86-64, including on CI in the test and test-fast jobs, if my extrapolation in #2065 (comment) from local test results comes to fruition), I predict that it will be a long while before I try to adapt the code to imara-diff 0.2.0, unless more information about it becomes available. I emphasize, however, that this is much more due to me not wanting to let it slow me down in doing more important things, than it is anything to do with imara-diff or the details of the changes.

There are at least four approaches we can take here, any of which I would consider good. We can leave this until I get back to it and either adapt to the new version of imara-diff or (much less likely, I think) discover a specific and compelling reason not to do so. Or if you want to take a look at it and take over, you can. Or f you want to take a look at it and not take over, but give a hint as to how I might fix things up for it, you can. Or if you prefer that the other crates be upgraded in the meantime even before imara-diff is upgraded, then please let me know and I'd be pleased to put imara-diff back temporarily, check to see if anything else breaks or generates new warnings, and fix up or make note of whatever else arises, merging the rest if it's ready.

[Byron]

Thanks for holding this PR.

It's strange that dependabot dares to upgrade between semver-incompatible versions, particularly in the pre-1.0 space that must cause a lot of breakage.

In any case, let's hold back imara-diff until we have found a way to deal with it.

As a matter of fact, I'd rather stick to 0.1 indefinitely than switching over to 0.2 as that development style and apparent lack of testing doesn't appear like it's anything gitoxide can afford. It has to work, and keep working, and for that tests are essential.

Speaking for v0.2 is the seeming availability of hunk-postprocessing to adjust sliders similar to what Git does, but without baseline tests comparing the two it's all wishful thinking to me. Also performance wise regressions are more than possible now, and it's lacking tests to detect that. So for now it seems best to keep v0.1 as simmering tech-debt (it also is undertested) and see where v0.2 goes - greater responsiveness of pascalkuthe would certainly go a long way to know what's up at least.

[dependabot]

Looks like these dependencies are no longer being updated by Dependabot, so this is no longer needed.

[EliahKagan]

In any case, let's hold back imara-diff until we have found a way to deal with it.

As a matter of fact, I'd rather stick to 0.1 indefinitely than switching over to 0.2 as that development style and apparent lack of testing doesn't appear like it's anything gitoxide can afford. It has to work, and keep working, and for that tests are essential.

In #2069, I've configured Dependabot so that Dependabot version updates for imara-diff will only be for patch versions, not for major or minor versions. (This does not affect Dependabot security updates--if a security vulnerability is fixed in a later minor or major version, Dependabot will still attempt to offer an update to a fixed version.)

Dependabot has closed this PR because it is creating a new one based on the modified configuration. The wording in #2068 (comment) is somewhat misleading, in that most of the affected dependencies continue to be fully covered by Dependabot version updates, and even imara-diff is capable of receiving them for a patch version.

Edit: The superseding Dependabot PR was #2070, which I've merged.