gix: allow sha256-only builds#2627
Conversation
Three call sites in gix/src/config referenced gix_hash::Kind::Sha1 unconditionally, which fails to compile when the Sha1 variant is feature-gated out of gix_hash::Kind. Replace the hardcoded Kind::Sha1 with the Default impl which is feature-aware (sha1 when available, otherwise sha256), so this preserves Sha1 as the default for normal builds while also letting sha256-only builds compile. For the core.rs Abbrev validator use Kind::longest() which accepts the widest range of valid lenghts. This only enfources a shape bound, the authoritative repo-hash check happens elsewhere (see comment). Add a Justfile check to verify the gix build. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 62de1ecc75
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "Codex (@codex) review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "Codex (@codex) address that feedback".
bfaa2bc to
99c75c8
Compare
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
This PR tightens repository object format handling to better match git behavior, particularly around extensions.objectFormat vs repository format versions, and improves build/test coverage for sha256-only configurations.
Changes:
- Reject
extensions.objectFormaton repository format version 0, and add a dedicated config error for that case. - Add fixtures + tests to assert v0 repositories with
extensions.objectFormatare rejected. - Adjust config validation/build checks to better support sha256-only builds.
Reviewed changes
Copilot reviewed 6 out of 7 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
justfile |
Adds a cargo check entry for --features sha256 to exercise sha256-only builds. |
gix/tests/gix/repository/open.rs |
Adds a regression test ensuring extensions.objectFormat on v0 repos is rejected. |
gix/tests/fixtures/make_config_repos.sh |
Creates new fixture repos with extensions.objectFormat set on v0 format repos. |
gix/src/config/tree/sections/core.rs |
Makes core.abbrev validation hash-kind-agnostic via Kind::longest(). |
gix/src/config/mod.rs |
Introduces ObjectFormatRequiresV1 config error variant. |
gix/src/config/cache/incubate.rs |
Implements new objectFormat/format-version logic and adds legacy_object_hash(). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
99c75c8 to
047458b
Compare
047458b to
7a3e783
Compare
A missing extensions.objectFormat means legacy Sha1. In sha256-only builds, Kind::default() is Sha256, so such repos were silently mislabeled as Sha256. Resolve the implicit case to Sha1 when supported, else error out to avoid any mislabeling. Also reject extensions.objectFormat when repositoryFormatVersion is 0, matching git, which treats it as an invalid v1-only extension. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
7a3e783 to
edf9793
Compare
There was a problem hiding this comment.
Just two minor suggestions, otherwise this is good to go from my side!
In comments we usually stick to SHA1 and SHA256 when referring to the hash kind. We also tend to use backticks for things like objectFormat and gix_hash::Kind::Sha1 (the latter could even be turned into a proper link).
Add fixtures with sha1 and sha256 variants and an open() test asserting that a version-0 repository setting extensions.objectFormat is rejected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
legacy_object_hash() has a feature-gated split: it returns Sha1 when the build supports it and an error otherwise. Add a unit test asserting the branch for the current build, and run the gix lib tests under --no-default-features --features sha256 so the error path is actually exercised in CI. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
edf9793 to
1b3ca28
Compare
Sebastian Thiel (Byron)
left a comment
There was a problem hiding this comment.
Thanks so much, and sorry for the long wait! Also thanks to Christoph Rüßler (@cruessler) for the initial review, it's much appreciated.
The most notable change I made here is to… change the prefixes of the commit message. There is know that we only do conventional commit messages for the purpose of controlling the changelog. In this case, a gix: prefix would probably have done nothing, but it might be confusing to look at. One of the commits is a genuine fix: and I made it so.
| #[error( | ||
| "extensions.objectFormat is a v1-only extension, but the repository format version is 0; \ | ||
| set core.repositoryFormatVersion=1 to use it, or remove extensions.objectFormat to fall back to the default Sha1 format (if supported by this build)" | ||
| )] | ||
| ObjectFormatRequiresV1, |
There was a problem hiding this comment.
A wonderful error message!
| // objectFormat is a "v1-only" extension: git refuses to operate on a version-0 repo that | ||
| // sets it, even for sha1 (unlike grandfathered extensions like preciousObjects, which v0 | ||
| // still honours). This rejection was introduced in git 2.29.0 (2020). We match it. |
There was a problem hiding this comment.
I like the research that went into this.
| #[cfg(not(feature = "sha1"))] | ||
| { | ||
| Err(Error::UnsupportedObjectFormat { name: "sha1".into() }) | ||
| } |
There was a problem hiding this comment.
I was a bit stuck here and decided to go with something else.
Initially, instead of saying this isn't possible, I asked myself what would Git do if it would allow to not compile SHA-1 in. Then I think it should just be like SHA-1 never happened, hence SHA-256 is returned.
However, Git doesn't do that and it gix tooling that relies on SHA-256 only builds will simply have to declare it properly so both Git and the tool can open it.
An interesting journey, leading to nothing but this comment 😁.
| } | ||
|
|
||
| #[cfg(test)] | ||
| mod tests { |
There was a problem hiding this comment.
This test felt redundant in the light of compile-time safety and docs of legacy_object_hash_reflects_build_features.
| git config extensions.objectFormat "$format" | ||
| git config core.repositoryFormatVersion 0 | ||
| ) | ||
| done |
There was a problem hiding this comment.
I removed the 'dance' in favor of something more direct, for better or worse.
|
Adrian Ratiu (@10ne1) I wasn't able to push my changes and review commit back into this branch which is an inconvenience, so I have to close this PR and let it be superseded by #2651. |
|
Sebastian Thiel (@Byron) I enabled |
What
This is part of #281 and fixes the following open item in that ticket:
It's 4 commits in total after addressing all feedback (including both Codex and Claude feedback). The most important concerns are:
AI disclosure
This PR was written with the help of Claude Code, but was not vibe-coded. I'm not a fan of vibe-coding. I used AI to better understand the codebase myself (asked it a lot of questions), review both my code and the code generated by AI, used it especially to detect bugs and corner-cases and suggest fixes, however I very carefully reviewed & edited each code/comment lines, the commit messages and so on, until I was myself satisfied with the result.