Cargo install --git fails with repo using sha256 object format

[Joshix-1]

Problem

cargo install --git https://codeberg.org/Joshix/rps fails

Steps

$ cargo install --git https://codeberg.org/Joshix/rps
    Updating git repository `https://codeberg.org/Joshix/rps`
error: failed to fetch into: /home/josh/.cargo/git/db/rps-7d405a448b2c5f11

Caused by:
  unknown remote object format 'sha256'; class=Invalid (3)

$ cargo +nightly -Zgitoxide install --git https://codeberg.org/Joshix/rps
    Updating git repository `https://codeberg.org/Joshix/rps`
error: failed to clone into: /home/josh/.cargo/git/db/rps-257013808e5f3c48

Caused by:
  failed to fill whole buffer

$ env CARGO_NET_GIT_FETCH_WITH_CLI=true cargo install --git https://codeberg.org/Joshix/rps
    Updating git repository `https://codeberg.org/Joshix/rps`
fatal: mismatched algorithms: client sha1; server sha256
error: failed to clone into: /home/josh/.cargo/git/db/rps-7d405a448b2c5f11

Caused by:
  process didn't exit successfully: `git fetch --force --update-head-ok 'https://codeberg.org/Joshix/rps' '+HEAD:refs/remotes/origin/HEAD'` (exit status: 128)

Possible Solution(s)

Support the sha256 object format

Notes

No response

Version

cargo 1.83.0 (5ffbef321 2024-10-29)
release: 1.83.0
commit-hash: 5ffbef3211a8c378857905775a15c5b32a174d3b
commit-date: 2024-10-29
host: x86_64-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Arch Linux Rolling Release [64-bit]

[epage]

Looks like libgit2 added support in 1.7.0, so we shouldn't be blocked on upstream.

[weihanglo]

Kinda blocked on rust-lang/git2-rs#1090 and GitoxideLabs/gitoxide#281

Still an upstream issue, though git2 is within cargo team's reach.

[weihanglo]

cc @Byron
no pressure :)

[Byron]

Thanks for the hint 😅!
I have added it to the list of requirements for Cargo, and once git2 adds the support for it that would pressure gitoxide to add such support as well.
On the bright side, support for it is already built-in to all of the code, but to assure basic functioning a lot of strategic tests would have to be written.

[Joshix-1]

Why doesn't cargo run git clone when CARGO_NET_GIT_FETCH_WITH_CLI=true is set? That could probably fix it with that setting.

[weihanglo]

Cargo internally maintains git datatbases from different repository. They are initialized and fetched in separate steps. We don't use git clone directly because 1) it has less customization points and 2) we don't want to assume a specific CLI tool exist on user's machine.

To make sha256 objectFormat just works for git CLI, we may need

• When Cargo initializes a git database, set the extension.objectFormat to sha256 (and repositoryformatversion to 1 maybe?). I am not particularly familiar with the migration plan and how to set up these configs properly.
  • It might be possible to check object-format capability during git negotiation, and set the necessary configurations.
• Internally Cargo checkouts source code to another directory when in use, this "local checkout" is facilitated by libgit2 now. To make it work, libgit2 must know how to do sha256 object format. The support is still in question, and could be a hard blocker.

Git CLI support was added for helping some weird networking issue on user side. From my understanding it is not a tool Cargo pursues for all its shiny new features, like lacking shallow clone support from git CLI integration. We normally see libgit2 as baseline, and nowadays gitoxide is our pioneer :)