Skip to content

Conversation

@cruessler
Copy link
Contributor

This is a follow-up to #2218 (which is a rewritten version of #2213). It marks gix_hash::Kind as non_exhaustive. This is a breaking change now, but will prevent further breaking changes whenever we add a new hashing algorithm in the future.

This is a follow-up to GitoxideLabs#2218 (which is a rewritten version of GitoxideLabs#2213). It
marks `gix_hash::Kind` as `non_exhaustive`. This is a breaking change
now, but will prevent further breaking changes whenever we add a new
hashing algorithm in the future.
Copy link
Member

@Byron Byron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot! I am surprised there isn't more breakage, which is good I suppose. Or is it 😅?

fn hash_to_byte(h: gix_hash::Kind) -> u8 {
match h {
gix_hash::Kind::Sha1 => 0,
_ => unreachable!("BUG: not implemented for hash kind {h}"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's too bad that it's not possible to allow the lint, instead of adding a fallback. That way, Gitoxide could opt-in to 'breaking' loudly once a new variant is added.
This makes me feel this non_exhaustive feature is really half-baked… why I can't we opt-out 😅?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It certainly tackles the problem from a specific angle. :-) I find it very useful, but as you say, there’s downsides in a monorepo.

@Byron Byron merged commit 264215b into GitoxideLabs:main Dec 10, 2025
28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants