Add GIX_TEST_FIXTURE_HASH to gix-testtools by cruessler · Pull Request #2377 · GitoxideLabs/gitoxide

cruessler · 2026-01-13T18:20:18Z

This PR adds the sha256 feature to gix-commitgraph. I opened it as a draft, so we have a space where we can discuss how to best approach testing this new feature.

This PR was triggered by a comment in #2359.

Byron · 2026-01-13T20:32:50Z

Thanks a lot, I am looking forward to sorting this out!

There is also #2378, hopefully done in the next couple of days (it might conflict).

Byron · 2026-01-14T05:49:40Z

Thanks a lot for starting this! This crate is special as it's the first one that parses a file-format that changes depending on the hash kind.

It seems like one commit currently in the gix-object PR would be useful here as well, in case you want to bring it up in its own PR.

cruessler · 2026-01-14T06:48:01Z

Assuming you’re referring to the one adding Kind::all (6d950f0), I’ll extract that addition into its own PR!

Apart from that, my plan is to go through the tests and, for every tests that currently uses sha1, add a corresponding one that uses sha256. Is that the way to go? Are there other things that would need to be done in this PR?

Byron · 2026-01-14T07:48:37Z

Assuming you’re referring to the one adding Kind::all (6d950f0), I’ll extract that addition into its own PR!

Yes, that's the one, thanks 🙏.

Apart from that, my plan is to go through the tests and, for every tests that currently uses sha1, add a corresponding one that uses sha256. Is that the way to go? Are there other things that would need to be done in this PR?

Sorry for the confusion, that's the way. The only thing tests have to do is to actively set all hashes using feature toggles, and they should just set sha1/sha256 while they are at it. Once a crate has been converted, the tests should automatically test both hashes, and make sure they are compiled in.

cruessler · 2026-01-18T13:57:08Z

I added fixtures for SHA256 hashes to gix-testtools and changed gix-commitgraph tests to run for all available hash kinds (those depend on the feature flags passed to gix-commitgraph). This seems to have worked on my machine, but I’m not sure I got the logic in gix-testtools right (any pointers would be much appreciated!). I also added gix-commitgraph to unit-test in justfile, and now I want to see what feedback CI has to give. :-)

tests/tools/src/lib.rs

cruessler · 2026-01-21T19:28:40Z

I think I’ve now gotten to a point where I need some feedback in order to be able to continue. (CI is still running, so I also might need to address any issue that comes up there.)

Specifically, I’ve got the following questions:

The PR runs tests for both hashes through cargo nextest run -p gix-commitgraph --features sha256 --no-fail-fast. Is that correct?
Last time CI ran it did not complain about any of the generated archives in gix-commitgraph, but when I delete both generated-archives as well as generated-do-not-edit in order to regenerate the archives, git status shows that most files have changed their size by 512 bytes and that one file has been both deleted and modified. (I’m running cargo test --features sha256 on Ubuntu 25.10.) What’s the best way to debug this?
Is there anything else I would need to change or include before I can mark this PR as ready?

# output of `gix status` inside `gix-commitgraph/tests/fixtures`
modified:   generated-archives/generation_number_overflow.tar
modified:   generated-archives/generation_number_overflow_sha256.tar
modified:   generated-archives/octopus_merges.tar
modified:   generated-archives/single_commit.tar
modified:   generated-archives/single_commit_huge_dates.tar
modified:   generated-archives/single_parent.tar
deleted:    generated-archives/single_parent_huge_dates.tar
modified:   generated-archives/two_parents.tar

Byron

I think this is great!

The PR runs tests for both hashes through cargo nextest run -p gix-commitgraph --features sha256 --no-fail-fast. Is that correct?

I made a note in Cargo.toml which should lead to the extra run in the justfile to be removed. Please take a look to see if it makes sense.

Last time CI ran it did not complain about any of the generated archives in gix-commitgraph, but when I delete both generated-archives as well as generated-do-not-edit in order to regenerate the archives, git status shows that most files have changed their size by 512 bytes and that one file has been both deleted and modified. (I’m running cargo test --features sha256 on Ubuntu 25.10.) What’s the best way to debug this?

generated-do-no-edit would be the folder to delete for it to restore from archive or regenerate the local cache in generated-do-not-edit. That's all there is to it. With the sha256 versions showing up, I'd expect it to want to create the sha256 versions which seems to have happened as well. It seems to work from my PoV, but I will take a closer look when reviewing properly.
PS: removing generated-archives will regenerate them, and they always appear changed. That's normal, and one would avoid deleting the tracked files.

Is there anything else I would need to change or include before I can mark this PR as ready?

It looks like it's ready for a non-armchair and final review after this one 🎉.

tests/tools/src/lib.rs

Byron · 2026-01-22T03:54:44Z

tests/tools/src/lib.rs

        .env_remove("GIT_WORK_TREE")
        .env_remove("GIT_COMMON_DIR")
        .env_remove("GIT_ASKPASS")
+        .env_remove("GIT_DEFAULT_HASH")


I think the remove here isn't needed if we are always overriding. If there is something special, then let's keep this and document it though.

Byron · 2026-01-22T03:56:14Z

gix-commitgraph/tests/access/mod.rs

-        "overflow happened, can't represent huge dates"
-    );
-    assert_eq!(
+    for hash_kind in gix_hash::Kind::all() {


Could all() rather return an iterator that hands out owned versions of hash_kind? I think that should work with impl Iterator<Item = Kind>.

Byron · 2026-01-22T04:00:37Z

gix-commitgraph/Cargo.toml


 [features]
+## Support for SHA256 hashes and digests.
+sha256 = ["gix-hash/sha256"]


I think we'd want to use dev-dependencies to always add sha256 to the features when testing. That way, there is only one way to run tests: all of them.

That means removing the feature here, is that correct?

Yes, let's start with that.

This means we say that plumbing will never set hash features, and it expects to be able to see the hash to be used at runtime via gix-hash::Kind. Most implementations do that already, and I think this should work for most cases.

Makes sense, removed.

Byron · 2026-01-22T06:39:02Z

As I am looking at Git for how they tackle this I wonder this: Should we, rather than changing every test and looping over it, prefer to build with all hashes, but run tests for each hash selectively, maybe by setting an environment variable that controls which hash is under test?

Performance-wise it should be very similar, even though development is a bit less convenient as one will have to run twice with different flags or environment variables set. There, having the tests run everything automatically, always, and what we have now, seems better.

Also, how do we handle expectations on hashes, particularly those with insta? It basically requires to chose one hash and find/replace the actual output to match that. I.e. insta::assert_debug_snapshot(hash.norm(actual), @r"expected with sha1"). And that remapping table, where would that come from? Is it passed in per function, or is it global? It can be global, and maybe that's how Git does it? I never checked, but it would be interesting to know.

So I think it's fine to keep this PR as is as it's happy with this simple and convenient solution, and we can probably layer moer on top of that when a need arises.

cruessler · 2026-01-22T07:39:40Z

I’m glad you mention this other option because I’m still very hesitant to force every test to be rewritten to make it loop over hash kinds as well. What I could try instead is adding an environment variable, e. g. GIX_TEST_HASH, that defaults to sha1 if not set, but can be changed to sha256. Any place that wants code to work regardless of hash kind wouldn’t have to bother, but could rely on CI as well as fixture script creation to take care of running with all hash kinds. I’ll try that approach in this PR!

cruessler · 2026-01-23T19:06:44Z

I’ve added a dev-depencency on gix-hash that activates the feature sha256, but I suspect that’s the reason why a couple of tests related to the size of objects now fail. At first sight, it looks like the feature is now enabled for every cargo nextest run. Apart from that, I think using an environment variable to set the hash per cargo nextest run works quite well.

Byron · 2026-01-26T04:14:07Z

I’m glad you mention this other option because I’m still very hesitant to force every test to be rewritten to make it loop over hash kinds as well. What I could try instead is adding an environment variable, e. g. GIX_TEST_HASH, that defaults to sha1 if not set, but can be changed to sha256. Any place that wants code to work regardless of hash kind wouldn’t have to bother, but could rely on CI as well as fixture script creation to take care of running with all hash kinds. I’ll try that approach in this PR!

That's fair, and probably that's best whenever there is no actual assertions against a hash.
When there is such assertions, one will have to touch these tests to have some sort of mapping, i.e. like with translations the test mentions only one kind of hash, probably SHA1, but it auto-translates to SHA256 when that's run.
Doing this ergonomically probably requires globals so one doesn't have to pass the hash kind in everywhere.

The manual looping is always something one can implement if that's a good choice in specific cases.

With such a system, we'd need just one more job to run the SHA256 version of the test suite, which just sets an environment variable.

I’ve added a dev-depencency on gix-hash that activates the feature sha256, but I suspect that’s the reason why a couple of tests related to the size of objects now fail. At first sight, it looks like the feature is now enabled for every cargo nextest run. Apart from that, I think using an environment variable to set the hash per cargo nextest run works quite well.

Oh, right, the nextest builds everything at once so has only one dependency tree for resolving feature flags.

If [dev-dependencies] would instead pull in gix-hash to enable one or more hashes (probably always all of them), then there would be no need for duplicating the hash related cargo features in the crate that uses gix-hash, and instead one would have to tell plumbing users to depend on gix-hash just to select hash features. This is what gix-features is there for, and maybe the hash selection could be added there as well.

In any case, it seems we'd have to find a way to get CI green. Something that I'd not want to lose is to see what the best possible size is, i.e. if just one hash is supported and that is the smallest hash. But then one would have to test the individual crate just with one hash kind which may also be difficult in future. So… maybe just change the size expectations to the new value, while also using [dev-dependencies] to enforce building with dual-hash support.

Byron · 2026-01-27T03:57:38Z

Oh, and what happens if the crate is now tested individually?
My feeling is that it needs its own feature toggles so that it knows what to test for… . If that's the case, I think we should add the respective statements to the justfile, every crate must be testable in isolation and work just the same.
Or… their tests can be adjusted to enforce all hashes as well, then there should be no difference. Probably my preference for now to keep it as simple as possible.

cruessler · 2026-01-27T07:00:54Z

We could add the following line to gix-pack/Cargo.toml which would make the failing test in gix-pack pass:

gix-hash = { version = "^0.22.0", path = "../gix-hash", features = ["sha256"] }

This would duplicate the dependency, though.

Byron · 2026-01-27T09:08:37Z

We could add the following line to gix-pack/Cargo.toml which would make the failing test in gix-pack pass:

Yes, such a line would be needed via [dev-dependencies], for all crates that had to be adjusted to compile with nextest.
On top of that, to play it safe, I think the justfile entry to test them individually would still be needed.

Lastly, it looks like there will never be a need to add sha1/sha256 feature toggle forwarding to crates that depend on gix-hash, so plumbing stays clean and expects its direct consumers to know they have to configure gix-hash on application level.

gix (the crate) would offer such a forwarding though with reasonable defaults. That seems quite minimal then.

justfile

cruessler · 2026-01-29T14:53:02Z

CI is now green! Quick summary of this PR’s changes:

It adds GIX_TEST_HASH which affects the default hash used in fixture scripts via GIT_DEFAULT_HASH. (We might want to consider renaming to GIX_TEST_FIXTURE_HASH or something that makes it clearer this is related to fixtures.)
It adapts size-of-various-objects-related expectations in tests so that the sizes always take both hash kinds into account.
For that to work consistently, it adds gix-hash = { …, features = ["sha256"] } to dev-dependencies in several crates.

Byron

Exciting!

It adds GIX_TEST_HASH which affects the default hash used in fixture scripts via GIT_DEFAULT_HASH. (We might want to consider renaming to GIX_TEST_FIXTURE_HASH or something that makes it clearer this is related to fixtures.)

Yes, I'd also like that.

I left a comment, but ideally it's applied to all the numbers so we keep track of the SHA1 versions.

Byron · 2026-02-01T14:42:41Z

gix-commitgraph/Cargo.toml


 [features]
+## Support for SHA256 hashes and digests.
+sha256 = ["gix-hash/sha256"]


Yes, let's start with that.

This means we say that plumbing will never set hash features, and it expects to be able to see the hash to be used at runtime via gix-hash::Kind. Most implementations do that already, and I think this should work for most cases.

gix-diff/src/tree/visit.rs

gix-pack/tests/Cargo.toml

tests/tools/src/lib.rs

justfile

Byron · 2026-02-01T15:06:30Z

gix-commitgraph/Cargo.toml

What surprises me is that there is no way to check what hash format the graph is using. Could we have an implementation of object_hash (which exists on File) for the Graph, and assert on the value.
But then we'd need a way to get the currently set hash, which had to come from gix-testtools.
I think this would be very useful to have and some assertion should definitely be made.

Are you thinking about something like the following:

/// The kind of hash used in this `Graph`. /// /// Note that it is always conforming to the hash used in the owning repository. /// /// # Panics /// /// If the graph does not contain any `File`. pub fn object_hash(&self) -> gix_hash::Kind { self.files .first() .map(super::File::object_hash) .expect("graph to have at least one file") }

Are you interested in a follow-up? There is the nonempty crate which I think would do wonders here (and in other places).

But besides that, yes, this is what I imagined.

Absolutely! I’ll have a look at nonempty. I assume we want to wrap self.files? Or are you thinking about a more local use just in object_hash?

I’ve now added Graph::object_hash.

cruessler · 2026-02-03T16:44:34Z

@Byron I’ve merged main and CI is green, so you can have another look if you want! Feel free to convert back to draft if you think it’s not ready yet!

Copilot

Pull request overview

This PR updates the test/fixture infrastructure and various dev-dependencies so SHA-256 object-format test runs can be supported (notably via hash-kind-specific fixtures and SHA-256-enabled gix-hash in test builds), and adds SHA-256 commitgraph fixtures.

Changes:

Add GIX_TEST_FIXTURE_HASH-driven fixture selection and pass hash kind into fixture scripts via GIT_DEFAULT_HASH.
Enable gix-hash’s sha256 feature across multiple crates’ test/dev builds and adjust size ceiling tests accordingly.
Add SHA-256 commitgraph fixture archives and update a test expectation to reflect the new fixture directory layout.

Reviewed changes

Copilot reviewed 24 out of 31 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
tests/tools/src/lib.rs	Add hash-kind-aware fixture selection and propagate hash kind into fixture scripts
tests/tools/Cargo.toml	Add `gix-hash` dependency required by new fixture selection logic
justfile	Run selected test packages under explicit hash-related env vars
gix/tests/gix/status.rs	Relax size expectations to account for SHA-256-enabled builds
gix/tests/gix/revision/spec/from_bytes/mod.rs	Update expected error path to include new `sha1` fixture directory segment
gix/tests/gix/object/mod.rs	Adjust size ceilings for SHA-256-enabled builds
gix/src/id.rs	Adjust size ceiling for SHA-256-enabled builds
gix/Cargo.toml	Enable `gix-hash/sha256` for `gix` dev/test builds
gix-worktree/tests/Cargo.toml	Enable `gix-hash/sha256` for test crate builds
gix-worktree-state/tests/Cargo.toml	Enable `gix-hash/sha256` for test crate builds
gix-revwalk/tests/revwalk.rs	Adjust size ceiling for SHA-256-enabled builds
gix-ref/src/raw.rs	Adjust size ceiling for SHA-256-enabled builds
gix-pack/tests/pack/iter.rs	Adjust size ceiling for SHA-256-enabled builds
gix-pack/tests/pack/data/output/mod.rs	Adjust size ceilings for SHA-256-enabled builds
gix-pack/tests/Cargo.toml	Update test crate metadata and enable `gix-hash/sha256`
gix-pack/src/cache/delta/tree.rs	Adjust large-array size ceiling for SHA-256-enabled builds
gix-pack/Cargo.toml	Enable `gix-hash/sha256` for `gix-pack` dev/test builds
gix-object/tests/object/main.rs	Adjust size ceiling for SHA-256-enabled builds
gix-negotiate/tests/negotiate.rs	Adjust size ceiling for SHA-256-enabled builds
gix-index/tests/index/mod.rs	Adjust size ceiling for SHA-256-enabled builds
gix-index/tests/Cargo.toml	Enable `gix-hash/sha256` for test crate builds
gix-index/src/extension/tree/mod.rs	Adjust size ceiling for SHA-256-enabled builds
gix-diff/src/tree/visit.rs	Adjust size ceiling for SHA-256-enabled builds
gix-commitgraph/tests/fixtures/generated-archives/single_parent_sha256.tar	Add SHA-256 fixture archive for commitgraph tests
gix-commitgraph/tests/fixtures/generated-archives/single_commit_sha256.tar	Add SHA-256 fixture archive for commitgraph tests
gix-commitgraph/Cargo.toml	Add SHA-256-enabled `gix-hash` dev-dependency for commitgraph tests
Cargo.lock	Record new `gix-hash` dependency edge for `tests/tools`

Copilot · 2026-02-07T04:10:56Z

tests/tools/src/lib.rs

+    let gix_test_hash = env::var_os("GIX_TEST_FIXTURE_HASH")
+        .and_then(|os_string| os_string.into_string().ok())
+        .unwrap_or_default();
+    let hash_kind = gix_hash::Kind::from_str(&gix_test_hash).unwrap_or_default();
+


GIX_TEST_FIXTURE_HASH values that fail to parse (including requesting sha256 when the gix-hash/sha256 feature isn’t enabled) currently fall back to the default hash via unwrap_or_default(). This can silently run tests/fixtures with SHA-1 while the caller believes SHA-256 is being exercised. Consider treating a non-empty env var that fails Kind::from_str() as an error (or at least emit a clear warning listing accepted values).

Yes, we should fail loudly.

I like that! Changed. (You might want to tune the specific behaviour.)

Copilot · 2026-02-07T04:10:57Z

justfile

+    env GIX_TEST_HASH=sha1 cargo nextest run -p gix-worktree-state-tests --features gix-features-parallel --no-fail-fast
+    env GIX_TEST_HASH=sha1 cargo nextest run -p gix-worktree-tests --features gix-features-parallel --no-fail-fast


GIX_TEST_HASH appears to be unused in the repository (no code reads it), so setting it here likely has no effect and may be confusing. Either remove these env GIX_TEST_HASH=... prefixes or switch to the env var that the test tooling actually consumes (e.g. GIX_TEST_FIXTURE_HASH for fixture selection).

Suggested change

env GIX_TEST_HASH=sha1 cargo nextest run -p gix-worktree-state-tests --features gix-features-parallel --no-fail-fast

env GIX_TEST_HASH=sha1 cargo nextest run -p gix-worktree-tests --features gix-features-parallel --no-fail-fast

env GIX_TEST_FIXTURE_HASH=sha1 cargo nextest run -p gix-worktree-state-tests --features gix-features-parallel --no-fail-fast

env GIX_TEST_FIXTURE_HASH=sha1 cargo nextest run -p gix-worktree-tests --features gix-features-parallel --no-fail-fast

My oversight, fixed.

Copilot · 2026-02-07T04:10:57Z

justfile

    cargo nextest run -p gix-pack-tests --features all-features --no-fail-fast
    cargo nextest run -p gix-pack-tests --features gix-features-parallel --no-fail-fast
-    cargo nextest run -p gix-index-tests --features gix-features-parallel --no-fail-fast
+    env GIX_TEST_HASH=sha1 cargo nextest run -p gix-index-tests --features gix-features-parallel --no-fail-fast


GIX_TEST_HASH appears to be unused in the repository (no code reads it), so setting it here likely has no effect and may be confusing. Either remove this env GIX_TEST_HASH=... prefix or switch to the env var that the test tooling actually consumes.

Suggested change

env GIX_TEST_HASH=sha1 cargo nextest run -p gix-index-tests --features gix-features-parallel --no-fail-fast

env GIX_TEST_FIXTURE_HASH=sha1 cargo nextest run -p gix-index-tests --features gix-features-parallel --no-fail-fast

My oversight, fixed.

gix-commitgraph/Cargo.toml

Byron · 2026-02-07T04:13:39Z

Thanks a lot! Yes, I think it's ready. I gave it another quick look and had a comment about object_hash(), ideally we can have it and use it in a test or two.
Once this is addressed, and it's non-conflicting, I will bring this PR to merge.

cruessler · 2026-02-07T05:52:09Z

Thanks a lot! Yes, I think it's ready. I gave it another quick look and had a comment about object_hash(), ideally we can have it and use it in a test or two. Once this is addressed, and it's non-conflicting, I will bring this PR to merge.

Awesome! I’ve tried to addressed the outstanding comments. I’ve also merged main. You probably want to double-check the result as I had to merge my changes with the ones coming from #2412. In particular, you might want to change the order of arguments or hash_kind as an argument to some functions.

Byron · 2026-02-08T10:15:37Z

Uff, I think I should add to the contribution guidelines to never merge main, but always rebase. While the diff is still what it's supposed to be, I feel 'unsafe' when it's unclear which commits are actually added here.

Would you fix that for me please?

cruessler · 2026-02-08T14:14:46Z

I’ve now rebased onto upstream/main. I’ll address any CI failures as they come in (which is why I’ve marked the PR as draft in the meantime). Unfortunately I had to already squash all commits into one as git only picked up the resolutions for tests/tools/src/lib.rs that were recorded during my first merge that way (I did want to manually resolve the same conflicts again). I hope this works for you and nothing got lost! This process also removed quite a few commits that had become redundant in the meantime, so it might even have improved the PR.

Byron

Thanks a lot, it's so much better!

If you don't mind, in the very sense of the words, could you split the commits up so only gix-commitgraph gets the feat: … ? Everything could probably be Adapt to changes… then.

Otherwise, and I'd understand, please feel free to bring this PR out of draft mode and I will edit some commits.

Thanks again (I really want to merge this one, has been going on for too long 😅, as becomes obvious by the website sluggishness).

cruessler · 2026-02-09T15:41:31Z

I’ve now split the PRs focusing on the addition of GIX_TEST_FIXTURE_HASH as most of the other changes were in response to that change. Feel free, though, to split along other lines if you think there’s a better way!

For now, there is no direct way to set it, but that may change once we have tests that need it. Co-authored-by: Sebastian Thiel <sebastian.thiel@icloud.com>

Copilot

Pull request overview

Copilot reviewed 27 out of 34 changed files in this pull request and generated no new comments.

- add object-hash test - add env variable docs - remove seemingly unnecessary fixture hash setup. Co-authored-by: chatgpt-codex-connector[bot] <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

Byron · 2026-02-15T11:56:05Z

justfile

+    env GIX_TEST_FIXTURE_HASH=sha1 cargo nextest run -p gix-commitgraph --no-fail-fast
+    env GIX_TEST_FIXTURE_HASH=sha256 cargo nextest run -p gix-commitgraph --no-fail-fast


@cruessler I have removed the other usages of gix-commitgraph as they just seemed to set the hash to SHA1 which doesn't seem necessary or effective anymore.

Byron

Thanks a lot! Overall this took quite a while to review and I have changed gix-testtools quite significantly to make it non-breaking.

It would probably be advisable to build up a guide that helps AI to formalise this conversion (similar to what's happening in #2423 .

cruessler · 2026-02-16T07:08:56Z

Thanks a lot! Overall this took quite a while to review and I have changed gix-testtools quite significantly to make it non-breaking.

Thanks a lot for the review as well as for the patience! Out of curiosity: was there anything I could have done that would have made reviewing or working with this PR in general easier?

It would probably be advisable to build up a guide that helps AI to formalise this conversion (similar to what's happening in #2423).

I’ll have a look! (Or are you already on it?) Are there any examples I could follow?

Byron · 2026-02-16T07:50:07Z

Thanks a lot for the review as well as for the patience! Out of curiosity: was there anything I could have done that would have made reviewing or working with this PR in general easier?

Thanks for asking. Unfortunately I have no answer except for a learning for myself: If it's something 'fundamental', I should just dabble in it myself and get the basics going, and of course, also get an understanding myself first. This PR had a lot of rounds, and I think there are diminishing returns if it's not merged fast enough.

I’ll have a look! (Or are you already on it?) Are there any examples I could follow?

I am not on it, but have an example in gix-error/src/lib.rs. That detailed guide was AI written, based on actual mistakes from the real world. I helped it write its own guide to hopefully do better in future. Maybe pick a next crate from the tasks section and see how the AI thing goes (if you want to use that at all). It certainly is a double-edged sword, as it's so great at making it appear like it's all sorted, even though only half of the work is done, and none of it properly 😅 (and I am saying that from my gix-error conversion experience which takes a ton of time to review).

Byron mentioned this pull request Jan 14, 2026

Sha 256 support #281

Open

23 tasks

cruessler mentioned this pull request Jan 14, 2026

feat: add Kind::all() #2381

Merged

cruessler force-pushed the add-sha-256-to-gix-commitgraph branch from bde9c33 to 7bc1409 Compare January 18, 2026 13:53

EliahKagan reviewed Jan 18, 2026

View reviewed changes

tests/tools/src/lib.rs Outdated Show resolved Hide resolved

loci-dev mentioned this pull request Jan 21, 2026

UPSTREAM PR #2377: feat: add sha256 feature to gix-commitgraph auroralabs-loci/gitoxide#1

Open

Byron reviewed Jan 22, 2026

View reviewed changes

EliahKagan reviewed Jan 28, 2026

View reviewed changes

justfile Outdated Show resolved Hide resolved

Byron reviewed Feb 1, 2026

View reviewed changes

loci-dev mentioned this pull request Feb 2, 2026

UPSTREAM PR #2377: feat: add sha256 feature to gix-commitgraph auroralabs-loci/gitoxide#15

Open

cruessler marked this pull request as ready for review February 3, 2026 16:44

Byron requested a review from Copilot February 7, 2026 04:05

Copilot started reviewing on behalf of Byron February 7, 2026 04:06 View session

Copilot AI reviewed Feb 7, 2026

View reviewed changes

Byron added the feedback requested label Feb 8, 2026

cruessler force-pushed the add-sha-256-to-gix-commitgraph branch from 4f01761 to ea0d591 Compare February 8, 2026 14:07

cruessler marked this pull request as draft February 8, 2026 14:07

Byron reviewed Feb 9, 2026

View reviewed changes

cruessler force-pushed the add-sha-256-to-gix-commitgraph branch from b05d9a7 to c8bef8d Compare February 9, 2026 15:32

cruessler changed the title ~~feat: add sha256 feature to gix-commitgraph~~ Add GIX_TEST_FIXTURE_HASH to gix-testtools Feb 9, 2026

cruessler marked this pull request as ready for review February 9, 2026 19:51

feat: use GIX_TEST_FIXTURE_HASH environment variable.

7f50c30

For now, there is no direct way to set it, but that may change once we have tests that need it. Co-authored-by: Sebastian Thiel <sebastian.thiel@icloud.com>

Byron force-pushed the add-sha-256-to-gix-commitgraph branch from c8bef8d to b37c3a9 Compare February 15, 2026 10:35

Byron requested a review from Copilot February 15, 2026 10:36

Copilot started reviewing on behalf of Byron February 15, 2026 10:36 View session

Copilot AI reviewed Feb 15, 2026

View reviewed changes

cruessler added 3 commits February 15, 2026 12:37

Use GIX_TEST_FIXTURE_HASH for gix-commitgraph and gix-pack.

d51b858

feat: Add Graph::object_hash()

dc06493

chore: improve crate description

5932e88

Byron force-pushed the add-sha-256-to-gix-commitgraph branch from b37c3a9 to 12e6b7b Compare February 15, 2026 11:43

refactor

8ccd760

- add object-hash test - add env variable docs - remove seemingly unnecessary fixture hash setup. Co-authored-by: chatgpt-codex-connector[bot] <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

Byron force-pushed the add-sha-256-to-gix-commitgraph branch from 12e6b7b to 8ccd760 Compare February 15, 2026 11:51

Byron reviewed Feb 15, 2026

View reviewed changes

Byron approved these changes Feb 15, 2026

View reviewed changes

Byron enabled auto-merge February 15, 2026 11:58

Byron merged commit 228caf7 into GitoxideLabs:main Feb 15, 2026
30 checks passed

		env GIX_TEST_HASH=sha1 cargo nextest run -p gix-worktree-state-tests --features gix-features-parallel --no-fail-fast
		env GIX_TEST_HASH=sha1 cargo nextest run -p gix-worktree-tests --features gix-features-parallel --no-fail-fast

	env GIX_TEST_HASH=sha1 cargo nextest run -p gix-index-tests --features gix-features-parallel --no-fail-fast
	env GIX_TEST_FIXTURE_HASH=sha1 cargo nextest run -p gix-index-tests --features gix-features-parallel --no-fail-fast

		env GIX_TEST_FIXTURE_HASH=sha1 cargo nextest run -p gix-commitgraph --no-fail-fast
		env GIX_TEST_FIXTURE_HASH=sha256 cargo nextest run -p gix-commitgraph --no-fail-fast

Uh oh!

Conversation

cruessler commented Jan 13, 2026

Uh oh!

Byron commented Jan 13, 2026

Uh oh!

Byron commented Jan 14, 2026

Uh oh!

cruessler commented Jan 14, 2026

Uh oh!

Byron commented Jan 14, 2026

Uh oh!

cruessler commented Jan 18, 2026

Uh oh!

Uh oh!

cruessler commented Jan 21, 2026

Uh oh!

Byron left a comment

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Byron commented Jan 22, 2026

Uh oh!

cruessler commented Jan 22, 2026

Uh oh!

cruessler commented Jan 23, 2026

Uh oh!

Byron commented Jan 26, 2026

Uh oh!

Byron commented Jan 27, 2026

Uh oh!

cruessler commented Jan 27, 2026

Uh oh!

Byron commented Jan 27, 2026

Uh oh!

Uh oh!

cruessler commented Jan 29, 2026

Uh oh!

Byron left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

Byron Feb 7, 2026 • edited 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!

cruessler commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Feb 7, 2026

Byron Feb 7, 2026 •

edited

Loading

cruessler commented Feb 3, 2026 •

edited

Loading

Byron left a comment •

edited

Loading