upgrade git-repository to gix 0.36.1; up min. rustc version to 1.64

[Byron]

This fixes breakage when installing helix due to an incorrect usage of as_ref() when interacting with bstr in the gitoxide codebase.

However, this upgrade also requires a higher rustc version, as gitoxide recently updated its windows crate version.

[pascalkuthe]

We currently have a MSRV of 1.63 (on purpose) and hence we can't update.
We are waiting for ubuntu to update their MSRV to 1.65 to avoid breaking too many users.
Helix is in an unusual position where a lot of users (instead of developers) are building helix from source.
Therefore MSRV is unusually important to us sadly.

Ubuntu is really annoying at the moment tough because they supposedly update their rustc version to match those of firefox: https://wiki.ubuntu.com/FoundationsTeam/RustUpdates

However at the moment rustc 1.65 is not yet in the ubuntu repos even tough firefox 110 is which requires rustc 1.65 (see https://changelogs.ubuntu.com/changelogs/pool/main/f/firefox/firefox_110.0+build3-0ubuntu0.20.04.1/changelog). The last time the firefox and rustc update happen simultaneously. The update to firefox 110 just happened 12 hours ago so lets hope that the update happens soon.

That being said the issue in GitoxideLabs/gitoxide#747 only occurs because the install instructions from the manual were not followed. Helix should be install with cargo install --locked.
Helix keeps a lockfile in the repo to avoid issues like this and only cargo install ignores that without that flag by default (other cargo commands always respect the lockfile).

[Byron]

Thanks for the update! Indeed, let's hope that the new rustc release will make it into the distro soon so this can move on. Also, it's good to hear that helix installation isn't technically broken due to the Cargo.lock file.

[devyn]

That being said the issue in Byron/gitoxide#747 only occurs because the install instructions from the manual were not followed. Helix should be install with cargo install --locked. Helix keeps a lockfile in the repo to avoid issues like this and only cargo install ignores that without that flag by default (other cargo commands always respect the lockfile).

Thanks for the clarification. Weird that cargo install doesn't expect the lockfile, I wouldn't have expected that.

[pascalkuthe]

Closing in favor #6185 which includes this PR.