fix(tree): std::path::Component has infallible conversion to &[u8]#2458
Merged
Sebastian Thiel (Byron) merged 3 commits intoGitoxideLabs:mainfrom Mar 22, 2026
Merged
Conversation
2d29cd8 to
b63a300
Compare
Instead of relying on a fallible path and using a default value, we can convert directly between a `Component` and a `&[u8]`.
b63a300 to
9ef21c7
Compare
Sebastian Thiel (Byron)
approved these changes
Mar 22, 2026
Member
Sebastian Thiel (Byron)
left a comment
There was a problem hiding this comment.
Thanks a lot, this is a great catch!
The previous implementation clearly worked around the fallibility of the conversion call, and the new version is faster with a similar failure mode: If this lookup is made on a platform with different-than-Git path encodings, and Git may try to turn paths to UTF-8, the equality comparison might not pan out.
But getting this right is hard as:
- it doesn't care about the case-sensivity settings of the repository
- it will happily compare different encodings and fail for that reason, with the only way to know how to do that by knowing which Git (for Windows) client was used to create the tree
So this seems to be an improvement, and for everything else let's wait and see.
- fix lint The previous implementation clearly worked around the fallibility of the conversion call, and the new version is faster with a similar failure mode: If this lookup is made on a platform with different-than-Git path encodings, and Git may try to turn paths to UTF-8, the equality comparison might not pan out. But getting this right is hard as: * it doesn't care about the case-sensivity settings of the repository * it will happily compare different encodings and fail for that reason, with the only way to know how to do that by knowing which Git (for Windows) client was used to create the tree So this seems to be an improvement, and for everything else let's wait and see.
9ef21c7 to
24a4d6b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The checks/conversions done in the
_by_pathmethods inTreeandTreeRefIterare unnecessary, so this PR removes them in favor of usingOsStr::as_encoded_bytes().Since
as_os_str().as_encoded_bytes()takes&selfand (as far as I know) no platforms use internal mutability onOsStr, the underlying value must already have the form we want. The only thing thatos_str_into_bstrdoes for us is validate that the byte string contains valid UTF-8. However, the only thing theseBStrs are used for is comparison to otherBStrs. Whether either of them is valid UTF-8 does not impact the function in any way (as string conversion errors are silently ignored), so we can simply skip the whole validation step and get ever-so-slightly-cheaper lookups by path.Please let me know if this change is useful/welcome or not, I can imagine that there may be some case I have not thought of that breaks from this change.