-
Notifications
You must be signed in to change notification settings - Fork 2.5k
sha256: refactoring in preparation for sha256 #6265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
8000Already on GitHub? Sign in to your account
Merged
Merged
Conversation
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
A tree entry previously pointed directly into the object id within the tree object itself; this is useful to avoid any unnecessary memory copy (and an unnecessary use of 40 bytes per tree entry) but difficult if we change the underlying `git_oid` object to not simply be a raw object id but have additional structure. This commit moves the `git_oid` directly into the tree entry; this simplifies the tree entry creation from user data. We now copy the `git_oid` into place when parsing.
Don't assume that a `git_oid` is a particular size; allocate `sizeof(git_oid)` instead.
We explicitly want to hash on the id data, not the beginning of the object data, which may contain other information in the future.
We explicitly want to write on the id data, not the beginning of the object data, which may contain other information in the future.
Don't write the object id structure, write its raw oid data.
Create an object id from raw data instead of casting.
We will talk about "raw" oids as untyped blobs of data; use a name for the comparison function that is in keeping with that.
Now that oids are type-aware, they use their type to understand how many bytes to copy. Some callers may need to copy the raw bytes of the object id. This is equivalent to a memcpy that is a little more semantic.
The commit graph contains arrays of raw oid data, use a byte array to index into them.
A packfile contains arrays of raw oid data, use a byte array to index into them.
The index contains entries with raw oid data, use a byte array for the raw entry data.
A multi-pack index uses raw oid data, use a byte array to index into them.
The indexer expects raw oid data, provide it.
f75e253
to
f882140
Compare
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.
Instead of treating
git_oid
as if it's simply an array of bytes, actually look at the internal byte array member. This is critical if we add additional data to thegit_oid
(like a type enum).(This is broken out of #6191.)