feat: unstable SHA256 support by weihanglo · Pull Request #1206 · rust-lang/git2-rs

weihanglo · 2026-01-12T23:44:54Z

This adds an unstable-sha256 Cargo feature, as a follow-up of #1201.
Also adds smoke tests for affected operations/types.

Part of #1090

Design

Introduce ObjectFormat accessors and *_ext API variants unconditionally,
The actual SHA256 wiring are gated behind the unstable-sha256 Cargo feature
in order to keep public API additive.

The *_ext suffix follows libgit2's convention for extended function variants.
At next major version, the original methods may absorb the format parameter.
The actual change will leave for future.

Insta-stable

NEW ObjectFormat enum (#[non_exhaustive] when unstable-sha256 is not enabled)
NEW Oid::ZERO_SHA1 const
NEW Oid::object_format() to access underlying OID type
NEW Oid::raw_bytes() to return the full underlying byte buffer
NEW Repository::object_format() to get hash algo on a repo
NEW Remote::object_format() to get hash algo on a remote
NEW RepositoryInitOptions::object_format() setter
NEW Oid::from_str_ext / Oid::hash_object_ext / Oid::hash_file_ext
NEW Diff::from_buffer_ext
NEW Index::new_ext / Index::open_ext
NEW Indexer::new_ext
NEW Odb::new_ext
DEPRECATED Oid::zero() in favor of Oid::ZERO_SHA1

Behind `unstable-sha256`

NEW ObjectFormat::Sha256 enum variant
NEW Oid::ZERO_SHA256 const
CHANGED All _ext methods dispatch to SHA256-aware FFI paths
CHANGED Oid::as_bytes returns logical bytes (SHA1 -> 20; SHA256 -> 32)
CHANGED Oid::from_bytes accepts 20 or 32 bytes

lorenzleutgeb · 2026-04-25T18:24:51Z

I believe to have found something that you missed in this PR. Note that git2::util::zeroed_raw_oid does not take any arguments:

git2-rs/src/util.rs

Lines 271 to 275 in e6919b7

    
           /// Creates a zeroed git_oid structure. 
        
           #[inline] 
        
           pub(crate) fn zeroed_raw_oid() -> raw::git_oid { 
        
               unsafe { std::mem::zeroed() } 
        
           }

I believe that this means that the kind: c_uchar (where c_uchar is defined as u8) member of the returned libgit2_sys::git_oid will have the value 0u8.

The function git2::util::zeroed_raw_oid is called by git2::Oid::zero, which also takes no arguments. If the function git2::Oid::object_format is called on the result of git2::Oid::zero, the call

git2-rs/src/oid.rs

Line 231 in e6919b7

unsafe { Binding::from_raw(self.raw.kind as raw::git_oid_t) }

will hit the panic! at

git2-rs/src/oid.rs

Line 29 in e6919b7

_ => panic!("Unknown git oid type"),

This is because 0u8 as u32 (which we got from std::mem::zeroed) is neither GIT_OID_SHA1 = 1, nor GIT_OID_SHA256 = 2.

I discovered this experimenting in code that is downstream of git2, building against this PR. In one of my tests I did essentially git2::Oid::zero().object_format().

Then I started to think about how much unsafe really is necessary here. Maybe zeroed_raw_oid could look like

#[inline]
pub(crate) fn zeroed_raw_oid(format: ObjectFormat) -> raw::git_oid {
  raw::git_oid {
    kind: format.raw(),
    id: [0; raw::GIT_OID_MAX_SIZE],
  }
}

In fact one might even ask why not to have

impl Oid {
  pub const ZERO_SHA1: Self = Self {
    raw: raw::git_oid {
      kind: raw::GIT_OID_SHA1,
      id: [0; raw::GIT_OID_MAX_SIZE],
    }
  };
  
  pub const ZERO_SHA256: Self = Self {
    raw: raw::git_oid {
      kind: raw::GIT_OID_SHA256,
      id: [0; raw::GIT_OID_MAX_SIZE],
    }
  };
  
  // NOTE: Maybe call this `zero_with_object_format` to not break `zero`.
  pub fn zero(format: ObjectFormat) -> Self {
    // TODO: Match on `format` and return `Oid::ZERO_SHA1` or `Oid::ZERO_SHA256`.
  }
}

This way, users that know at compile time which kind of zero they want can just use the constant, while those that decide at run time would call zero. And there is no unsafe involved.

If you do not want git2::Oid::zero to take an argument for backwards compatibility, then you could have it return a SHA-1 object identifier always, and mark it deprecated in favor of these constants and a new zero_with_object_format (if I have not missed a reason why the constants cannot be used).

For oid.rs I also had the gut feeling that some unsafe could be removed, but I do not have any constructive comments here, sorry.

lorenzleutgeb · 2026-04-25T18:47:18Z

Another comment regarding FromStr: I understand you opted to remove it to "avoid misuse", but I would argue that having FromStr actually is quite convenient. Instead of removing it, you could consider implementing FromStr in a way that it checks the length of the argument and then calls into the more specialized function that takes a string and an object format. The caller can then still inspect the object format of the result. You leave all options open for your users, and keep backwards compatibility.

DanielEScherzer

just some thoughts, not going to pretend that I understand this fully

View changes since this review

DanielEScherzer · 2026-04-27T22:33:42Z

+        #[cfg(not(feature = "unstable-sha256"))]
+        {
+            if bytes.len() != raw::GIT_OID_SHA1_SIZE {
+                return Err(Error::from_str("raw byte array must be 20 bytes"));


maybe a clearer error for trying to accidentally use 32 bytes when the feature isn't enabled?

Also, why have different ways of creating the SHA1 oid depending on if the SHA256 feature is available?

let oid_type = match bytes.len() { raw::GIT_OID_SHA1_SIZE => raw::GIT_OID_SHA1, #[cfg(feature = "unstable-sha256")] raw::GIT_OID_SHA256_SIZE => raw::GIT_OID_SHA256, #[cfg(not(feature = "unstable-sha256"))] raw::GIT_OID_SHA256_SIZE => { return Err(Error::from_str( "raw byte array of 32 bytes requires unstable-sha256 feature to be enabled", )) } _ => { return Err(Error::from_str( "raw byte array must be 20 bytes (SHA1) or 32 bytes (SHA256, if enabled)", )) } }; unsafe { try_call!(raw::git_oid_from_raw(&mut raw, bytes.as_ptr(), oid_type)); } Ok(Oid { raw })

Good suggestion, though I am not sure if here we should talk about unstable-sha256 feature, downstream consumer of git2-rs may just propagate error message to end-users, and that might be weird to see that.

If the error message is propagated to end users, presumably the end users had some kind of say in the input value

DanielEScherzer · 2026-04-27T22:37:08Z

+        }
+        #[cfg(not(feature = "unstable-sha256"))]
+        {
+            let _ = oid_type;


hmm, even if the git2-rs bindings don't have SHA256 enabled, if the oid_type corresponds to SHA256 we should say that and probably return an error, rather than just claiming that the repository is formatted with SHA1?

IIUC, without unstable-sha256, the underlying libgit2-sys can't return a SHA256 oid or even open a SHA256 repo.

What if the underlying library was built with sha256 enabled, but the git2 crate wasn't?

AFAIK none of the mainstream packagers distribute libgit2.so with SHA256 support. The reason being it was broken before libgit2 1.9.3 (released a week ago). Also when sha256 is enabled, libgit2 built a shared libray with -experimental suffix. Unless packager intentionally patch that build script to remove the suffix, it is pretty distinguishable. However, it is unlikely someone does that, since the two are ABI incompatible and doing that breaks other programs dynamically linking to it.

I also raised this concern in rust-lang/cargo#16939 (comment) but from the other angle – Cargo may need to build from source always as nobody ships libgit2-experimental.so.

weihanglo · 2026-05-07T22:51:12Z

Another comment regarding FromStr: I understand you opted to remove it to "avoid misuse", but I would argue that having FromStr actually is quite convenient. Instead of removing it, you could consider implementing FromStr in a way that it checks the length of the argument and then calls into the more specialized function that takes a string and an object format. The caller can then still inspect the object format of the result. You leave all options open for your users, and keep backwards compatibility.

This is still ambiguous for those not 41-64 char hex strings. I'd still consider deprecating it and eventually remove.
Alternatively, we just keep it there and have a compatibility note.

weihanglo

New revision is up.

The major difference is that we stop follow libgit2@main but 1.9.3. The other is API design, which is stated in the PR description:

Introduce ObjectFormat accessors and *_ext API variants unconditionally,
The actual SHA256 wiring are gated behind the unstable-sha256 Cargo feature
in order to keep public API additive.

The *_ext suffix follows libgit2's convention for extended function variants.
At next major version, the original methods may absorb the format parameter.
The actual change will leave for future.

View changes since this review

weihanglo · 2026-05-08T00:27:17Z

cc @ehuss

lorenzleutgeb

I will double down on what I explained in #1206 (comment): If the feature unstable-sha256 is enabled, the implementation of the unsafe function crate::util::zeroed_raw_oid is incorrect. It allows to create OIDs in memory, which are invalid. Their kind of value zero does not correspond to a known git2::ObjectFormat and also neither to libgit2's GIT_OID_SHA1 nor GIT_OID_SHA256. That is because the function uses std::mem::zeroed but the object formats are non-zero bytes. This is a huge footgun. Please consider these options:

Remove crate::util::zeroed_raw_oid.
Remove the unsafe keyword from crate::util::zeroed_raw_oid and reimplement it without unsafe blocks. This will force you to add an argument format: git2::ObjectFormat, otherwise, if unstable-sha256 is enabled, you will not be able to construct a legal zero OID.
Use #[cfg(not(feature = "unstable-sha256"))] crate::util::zeroed_raw_oid.

View changes since this review

lorenzleutgeb · 2026-05-08T08:01:55Z

    Sha1,
+    /// SHA256 object format (32-byte object IDs)
+    #[cfg(feature = "unstable-sha256")]
+    Sha256,


Consider using an explicit discriminant that matches with libgit2. Like

Suggested change

Sha256,

Sha256 = raw::GIT_OID_SHA256,

or

Suggested change

Sha256,

Sha256 = 2,

Thanks for the suggestion. Some of the pre-existing translation enums in git2-rs follow the plain enum + Binding + explicit match pattern. libgit2_sys::git_oid_t is a numeric type alias, and ObjectFormat is the safe abstraction over it. Explicit discriminants would definitly simplify ObjectFormat::raw(), though from_raw still needs the match for safety against invalid C values. I'd keep ObjectFormat as-is for now.

lorenzleutgeb · 2026-05-08T08:08:57Z


 /// Object ID format (hash algorithm).
 #[derive(Debug, Copy, Clone, PartialEq, Eq)]
+#[non_exhaustive]


I should have been more explicit when I suggested this in #1090 (comment), sorry.

Adding #[non_exhaustive] breaks downstream crates, since their matches will fail to compile. Thus I think this is a breaking change. This might be completely fine, as this crate is 0.x anyway, but I think it's worth noting. That being said...

Adding #[non_exhaustive] even when unstable-sha256 is enabled, might be "too much". This way you are preparing your users for whatever comes after SHA-256. Which might be your intention, and then that's fine. But you might as well consider that it might take another decade or two until that happens, and you could spare your dependents the _ => unimplemented!("...") arm. This would mean that adding the next object format is a breaking change. And that might be fine as well.

So one approach might be to have

Suggested change

#[non_exhaustive]

#[cfg_attr(not(feature = "unstable-sha256"), non_exhaustive)]

now, and whenever SHA-256 becomes stable, to remove non_exhaustive.

This way, all dependents not enabling unstable-sha256 will be forced to think about further object formats (which might make sense, since SHA-256 is already out in the wild), and everyone that opts in to unstable-sha256 can enjoy that this enum is exhaustive. The migration (as SHA-256 stabilizes) also works out nicely: The _ => unimplemented!("...") arm nicely takes the spot of the Sha256 variant, but since now the non_exhaustive attribute would be removed no third arm is required once the dependent decides to implement support for SHA-256.

Then this is probably not worthy. We will anyway have another major version bump when stabilizing sha256 feature.

Think about it more, yeah this sounds good.

Fixed and squashed into 17d0f51. Thanks again for the forward-looking suggestion!

lorenzleutgeb · 2026-05-08T08:14:58Z

+#[non_exhaustive]
 pub enum ObjectFormat {
    /// SHA1 object format (20-byte object IDs)
    Sha1,


Suggested change

Sha1,

Sha1 = raw::GIT_OID_SHA1,

or

Suggested change

Sha1,

Sha1 = 1,

(See https://github.com/rust-lang/git2-rs/pull/1206/changes#r3207277482.)

lorenzleutgeb · 2026-05-08T08:19:23Z

@@ -65,36 +106,78 @@ impl Oid {
    pub fn from_bytes(bytes: &[u8]) -> Result<Oid, Error> {
        crate::init();
        let mut raw = crate::util::zeroed_raw_oid();


If unstable-sha256 is enabled, raw.kind will be zero and thus not a valid object format!

@lorenzleutgeb commented in #1206 (review)

(inline comment is better for discussion)

I will double down on what I explained in #1206 (comment): If the feature unstable-sha256 is enabled, the implementation of the unsafe function crate::util::zeroed_raw_oid is incorrect. It allows to create OIDs in memory, which are invalid. Their kind of value zero does not correspond to a known git2::ObjectFormat and also neither to libgit2's GIT_OID_SHA1 nor GIT_OID_SHA256. That is because the function uses std::mem::zeroed but the object formats are non-zero bytes. This is a huge footgun. Please consider these options:

Remove crate::util::zeroed_raw_oid.

Remove the unsafe keyword from crate::util::zeroed_raw_oid and reimplement it without unsafe blocks. This will force you to add an argument format: git2::ObjectFormat, otherwise, if unstable-sha256 is enabled, you will not be able to construct a legal zero OID.

Use #[cfg(not(feature = "unstable-sha256"))] crate::util::zeroed_raw_oid.

Thanks for the detailed follow-up. Will do a cleanup then, though let me clarify the current state:

Oid::zero() is now deprecated and returns Oid::ZERO_SHA1 always. The reasoning being high-level binding should not have this kind of zeroed struct as output param. If there is any probably an API design flaw. If people want oid placeholder, they probalby already know the object format so can choice either const. Tthanks for the const suggestion!

zeroed_raw_oid() is pub(crate). Every internal call site uses it as an output parameter that libgit2 overwrites before any read. Agreed it may become an internal footgun if misused.

FWIW, libgit2 itself uses uninitialized git_oid as output buffers in lots of places. Like maybe_sha_or_abbrev: git_oid oid; is declared uninitialized, then filled by git_oid__fromstrn(&oid, ...) before any read.

Though thanks again, removing one more unsafe is a good thing! Fixed in 8c17e75

The only one concern is that if libgit2 somehow start checking kind for output parameter cases, it might become buggy. Though that will be considered an upstream libgit2 bug.

This is a preparation of SHA256 support * Added `Oid::object_format()` * Added `Oid::raw_bytes()` * Changed `Oid::from_bytes()` to use `GIT_OID_SHA1_SIZE` * Added `Repository::object_format()` * Added `Remote::object_format()` * Added `RepositoryInitOptions::object_format()`

Add `*_ext` method variants that accept an `ObjectFormat` param. The short-hand methods now delegate to `_ext` variants with Sha1. * Added `Oid::from_str_ext` * Added `Oid::hash_object_ext` * Added `Oid::hash_file_ext` * Added `Diff::from_buffer_ext` * Added `Index::new_ext` * Added `Index::open_ext` * Added `Indexer::new_ext` * Added `Odb::new_ext`

This makes these call sites automatically handle the correct object format once SHA256 support is wired up.

Declare the `unstable-sha256` Cargo feature, reflecting upstream libgit2's `GIT_EXPERIMENTAL_SHA256`. This is an ABI-breaking experimental feature. Implement the SHA256 support gated behind this feature: Things gated: * `ObjectFormat::Sha256` and non_exhaustive when `unstable-sha256` is off * all FFI call sites for the overloaded libgit2 function signatures * git_oid_fromstrn * git_oid_fromraw, * git_odb_hash * git_odb_hashfile * git_diff_from_buffer, * git_index_new * git_index_open * git_indexer_new * git_odb_new * `Repository::object_format` is format-aware * `Remote::object_format` is format-aware * `Oid::{as_bytes,object_format,from_bytes}` are format-aware

`Oid::zero().object_format()` panics with `unstable-sha256` because the raw `kind` field was left as zero. The zeroed struct is generally use for output param. Not really meaning to switch a `zero_ext` variant. Replace it with const values for both kinds.

Construct `git_oid` with a struct literal instead of `mem::zeroed`. Under `unstable-sha256`, default `kind` to `GIT_OID_SHA1` so the value is a valid `git_oid_t` even before libgit2 overwrites it as an output buffer.

rustbot · 2026-05-08T12:29:19Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

lorenzleutgeb · 2026-05-08T14:00:01Z

 /// Object ID format (hash algorithm).
 #[derive(Debug, Copy, Clone, PartialEq, Eq)]
+#[cfg_attr(not(feature = "unstable-sha256"), non_exhaustive)]
 pub enum ObjectFormat {


Downstream I just attempted to print an ObjectFormat and realized that it does not impl Display. Perhaps that might be a useful addition?

View changes since the review

DanielEScherzer · 2026-05-09T15:51:13Z

    /// permissions to create the repository with
    flag_shared: Option<String>,
+    #[structopt(name = "object-format", long, value_parser = parse_object_format)]
+    /// object format to use (sha1 or sha256, requires unstable-sha256 feature)


Suggested change

/// object format to use (sha1 or sha256, requires unstable-sha256 feature)

/// object format to use (sha1 or sha256, requires unstable-sha256 feature to use the sha256 format)

View changes since the review

DanielEScherzer · 2026-05-09T15:52:52Z

+    /// This parses the diff assuming SHA1 object IDs. Use
+    /// [`Diff::from_buffer_ext`] to specify a different format.
    pub fn from_buffer(buffer: &[u8]) -> Result<Diff<'static>, Error> {
+        Self::from_buffer_ext(buffer, crate::ObjectFormat::Sha1)


I can't make suggestions on the unmodified line, but I suggest adding an import for crate::ObjectFormat rather than needing to fully qualify it

View changes since the review

DanielEScherzer · 2026-05-09T15:53:30Z

+        let data = buffer.as_ptr() as *const c_char;
+        let len = buffer.len();
        unsafe {
-            // NOTE: Doesn't depend on repo, so lifetime can be 'static


this explanation of why things can be 'static is lost

View changes since the review

DanielEScherzer · 2026-05-09T15:53:59Z

+    /// This always creates a SHA1 index.
+    /// Use [`Index::new_ext`] to create an index with a specific object format.
    pub fn new() -> Result<Index, Error> {
+        Self::new_ext(crate::ObjectFormat::Sha1)


same suggestion to add a use statement for the ObjectFormat, also applies in some other files, not going to keep repeating the suggestion

View changes since the review

DanielEScherzer · 2026-05-09T15:57:48Z

+    /// Parses a hex-formatted object id
+    /// with a specific object format.
+    ///
+    /// See [`Oid::from_str`] for more details.


except ::from_str documents that it is an error if the string is longer than 40 hex characters, and presumably for this new method the maximum length is format-dependent, so this method should have some extra documentation

View changes since the review

DanielEScherzer · 2026-05-09T15:59:45Z

+        #[cfg(not(feature = "unstable-sha256"))]
+        {
+            if bytes.len() != raw::GIT_OID_SHA1_SIZE {
+                return Err(Error::from_str("raw byte array must be 20 bytes"));


If the error message is propagated to end users, presumably the end users had some kind of say in the input value

DanielEScherzer · 2026-05-09T16:01:08Z

        Ok(Oid { raw: out })
    }

    /// View this OID as a byte-slice 20 bytes in length.


can we document that this is going to truncate sha256 ids?

View changes since the review

I'm not sure I understand, why would this truncate?

I would agree that the doc comment should probably be updated, though, to mention it can be 32 bytes for sha256.

DanielEScherzer · 2026-05-09T16:02:13Z

+
+    /// View the full underlying byte buffer of this OID.
+    ///
+    /// Currently equivalent to [`Oid::as_bytes`].


This is a bin confusing - the "Currently equivalent" assumes that the feature is not enabled, but then the next line discusses that it could be enabled. Maybe

Suggested change

/// Currently equivalent to [`Oid::as_bytes`].

/// For SHA1 hashes, this is equivalent to [`Oid::as_bytes`].

View changes since the review

DanielEScherzer · 2026-05-09T16:04:41Z

    use tempfile::TempDir;

    #[test]
+    #[cfg(not(feature = "unstable-sha256"))]


so I noticed this on a few other files too - why are various tests disabled when using unstable-sha256? If they would be failing, then that is indicative of a BC break, and if they would be passing, then we should presumably keep the tests enabled?

View changes since the review

DanielEScherzer · 2026-05-09T16:07:06Z

+
+        // SHA1 OID comparisons with explicit format
+        assert_eq!(
+            Oid::from_str_ext("decbf2b", ObjectFormat::Sha1)?,


similarly, for the *_ext methods when using Sha1, those parts can also be tested even when sha256 support is not enabled

View changes since the review

ehuss · 2026-05-11T14:26:25Z

Note: Git 3 will switch to reftable by default (source). Reftable support was only just merged in libgit2/libgit2#7117 which presumably will be in libgit2 2.0. SHA256 support is a major step towards being compatible with git3, but reftable will be another large piece that will be required. Fortunately I don't think that requires any API changes, though we should probably plan to do some testing ahead of the libgit2 2.0 release.

ehuss · 2026-05-11T14:02:23Z

-    - run: cargo test --features https,ssh
    - run: cargo run -p systest
    - run: cargo run -p systest --features unstable-sha256
+    - run: cargo test --locked


Moving these breaks the --locked check since the earlier cargo run will update the lockfile. Can you either move them back, or add --locked to the other commands?

View changes since the review

ehuss · 2026-05-11T14:03:50Z

    - run: cargo run -p systest --features unstable-sha256
+    - run: cargo test --locked
+    - run: cargo test --features https,ssh
+    - run: cargo test --features unstable-sha256


Can we also make sure this covers networking (and examples)? Maybe something like:

Suggested change

- run: cargo test --features unstable-sha256

- run: cargo test --features https,ssh,unstable-sha256

View changes since the review

ehuss · 2026-05-11T14:36:20Z

+            #[cfg(not(feature = "unstable-sha256"))]
            id: Oid::from_bytes(&[0; 20]).unwrap(),
+            #[cfg(feature = "unstable-sha256")]
+            id: Oid::from_bytes(&[0; 32]).unwrap(),


Just a suggestion, take it or leave it:

Suggested change

#[cfg(not(feature = "unstable-sha256"))]

id: Oid::from_bytes(&[0; 20]).unwrap(),

#[cfg(feature = "unstable-sha256")]

id: Oid::from_bytes(&[0; 32]).unwrap(),

#[cfg(not(feature = "unstable-sha256"))]

id: Oid::ZERO_SHA1,

#[cfg(feature = "unstable-sha256")]

id: Oid::ZERO_SHA256,

View changes since the review

I suggested these constants, so that will surprise no one, but I second that suggestion. More readable and less unwraping!

ehuss · 2026-05-11T14:37:04Z

+
+    #[test]
+    #[cfg(feature = "unstable-sha256")]
+    fn smooke_in_memory_index_sha256() {


Suggested change

fn smooke_in_memory_index_sha256() {

fn smoke_in_memory_index_sha256() {

View changes since the review

ehuss · 2026-05-11T14:52:25Z

        Ok(Oid { raw: out })
    }

    /// View this OID as a byte-slice 20 bytes in length.


I'm not sure I understand, why would this truncate?

I would agree that the doc comment should probably be updated, though, to mention it can be 32 bytes for sha256.

ehuss · 2026-05-11T14:55:06Z

+    /// With the `unstable-sha256` feature, these two methods will differ.
+    pub fn raw_bytes(&self) -> &[u8] {


Why was this method added? I don't see it used anywhere.

View changes since the review

#1206 (comment)

ehuss · 2026-05-11T15:56:19Z

+#[cfg(feature = "unstable-sha256")]
+pub fn repo_init_sha256() -> (TempDir, Repository) {


Instead of duplicating the code here, can we merge them somehow?

I might suggest having a repo_init_ext that takes an ObjectFormat as a parameter, and rewrite repo_init to just call repo_init_ext(ObjectFormat::Sha1).

Or any other approach, just try to remove the duplicate code.

View changes since the review

weihanglo force-pushed the sha256-git2 branch 7 times, most recently from dd35da4 to a332c64 Compare January 13, 2026 18:53

weihanglo force-pushed the sha256-git2 branch from a332c64 to fd975c7 Compare February 10, 2026 06:46

bentenjamin mentioned this pull request Feb 16, 2026

[Feature]: Add support for SHA256 object format ViscousPot/GitSync#360

Open

jorendorff reviewed Feb 24, 2026

View reviewed changes

Comment thread src/oid.rs Outdated

weihanglo force-pushed the sha256-git2 branch from fd975c7 to 23c005f Compare March 16, 2026 14:24

weihanglo mentioned this pull request Mar 16, 2026

SHA-256 #1090

Open

weihanglo force-pushed the sha256-git2 branch from 23c005f to fc6f290 Compare March 16, 2026 15:27

weihanglo force-pushed the sha256-git2 branch from fc6f290 to c590157 Compare April 5, 2026 13:21

weihanglo force-pushed the sha256-git2 branch 2 times, most recently from c07b123 to 5c04d59 Compare April 16, 2026 12:29

This was referenced Apr 19, 2026

fix(clone): propagate object format in local clone libgit2/libgit2#7226

Merged

Support SHA256 Git repositories rust-lang/cargo#14942

Open

weihanglo force-pushed the sha256-git2 branch from 5c04d59 to e6919b7 Compare April 24, 2026 13:05

DanielEScherzer reviewed Apr 27, 2026

View reviewed changes

lorenzleutgeb mentioned this pull request Apr 30, 2026

WIP: Handling of zero weihanglo/git2-rs#1

Closed

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-author Status: Waiting on PR author label May 5, 2026

weihanglo force-pushed the sha256-git2 branch 2 times, most recently from 9b1f12d to 5778238 Compare May 8, 2026 00:03

weihanglo commented May 8, 2026

View reviewed changes

weihanglo marked this pull request as ready for review May 8, 2026 00:27

rustbot added the S-waiting-on-review Status: Waiting on review label May 8, 2026

weihanglo removed the S-waiting-on-author Status: Waiting on PR author label May 8, 2026

weihanglo changed the title ~~[WIP] feat: unstable SHA256 support~~ feat: unstable SHA256 support May 8, 2026

lorenzleutgeb suggested changes May 8, 2026

View reviewed changes

weihanglo added 8 commits May 8, 2026 08:25

refactor: format-aware OID parsing via *_ext fn

f8bf444

This makes these call sites automatically handle the correct object format once SHA256 support is wired up.

refactor(util): drop unsafe from zeroed_raw_oid

8c17e75

Construct `git_oid` with a struct literal instead of `mem::zeroed`. Under `unstable-sha256`, default `kind` to `GIT_OID_SHA1` so the value is a valid `git_oid_t` even before libgit2 overwrites it as an output buffer.

fix: init example with --object-format option

aa866f6

chore(ci): test git2 sha256 support

79d5e2b

weihanglo force-pushed the sha256-git2 branch from 5778238 to 79d5e2b Compare May 8, 2026 12:29

weihanglo mentioned this pull request May 8, 2026

docs: prepare changelog for git2@0.21.0 #1248

Open

lorenzleutgeb reviewed May 8, 2026

View reviewed changes

DanielEScherzer reviewed May 9, 2026

View reviewed changes

ehuss reviewed May 11, 2026

View reviewed changes

	#[non_exhaustive]
	#[cfg_attr(not(feature = "unstable-sha256"), non_exhaustive)]

	/// object format to use (sha1 or sha256, requires unstable-sha256 feature)
	/// object format to use (sha1 or sha256, requires unstable-sha256 feature to use the sha256 format)

	/// Currently equivalent to [`Oid::as_bytes`].
	/// For SHA1 hashes, this is equivalent to [`Oid::as_bytes`].

	- run: cargo test --features unstable-sha256
	- run: cargo test --features https,ssh,unstable-sha256

	fn smooke_in_memory_index_sha256() {
	fn smoke_in_memory_index_sha256() {

		/// With the `unstable-sha256` feature, these two methods will differ.
		pub fn raw_bytes(&self) -> &[u8] {

		#[cfg(feature = "unstable-sha256")]
		pub fn repo_init_sha256() -> (TempDir, Repository) {

Conversation

weihanglo commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Design

Insta-stable

Behind unstable-sha256

Uh oh!

Uh oh!

lorenzleutgeb commented Apr 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lorenzleutgeb commented Apr 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DanielEScherzer left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

weihanglo commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

weihanglo left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

weihanglo commented May 8, 2026

Uh oh!

lorenzleutgeb left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented May 8, 2026

Uh oh!

lorenzleutgeb May 8, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DanielEScherzer May 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

weihanglo commented Jan 12, 2026 •

edited

Loading

Behind `unstable-sha256`

lorenzleutgeb commented Apr 25, 2026 •

edited

Loading

lorenzleutgeb commented Apr 25, 2026 •

edited

Loading

DanielEScherzer left a comment •

edited by rustbot

Loading

weihanglo commented May 7, 2026 •

edited

Loading

weihanglo left a comment •

edited by rustbot

Loading

lorenzleutgeb left a comment •

edited by rustbot

Loading

lorenzleutgeb May 8, 2026 •

edited by rustbot

Loading

DanielEScherzer May 9, 2026 •

edited by rustbot

Loading

DanielEScherzer May 9, 2026 •

edited by rustbot

Loading

DanielEScherzer May 9, 2026 •

edited by rustbot

Loading

DanielEScherzer May 9, 2026 •

edited by rustbot

Loading

DanielEScherzer May 9, 2026 •

edited by rustbot

Loading

DanielEScherzer May 9, 2026 •

edited by rustbot

Loading

DanielEScherzer May 9, 2026 •

edited by rustbot

Loading

DanielEScherzer May 9, 2026 •

edited by rustbot

Loading

DanielEScherzer May 9, 2026 •

edited by rustbot

Loading

ehuss May 11, 2026 •

edited by rustbot

Loading

ehuss May 11, 2026 •

edited

Loading