8000 sha256: refactoring in preparation for sha256 by ethomson · Pull Request #6265 · libgit2/libgit2 · GitHub
[go: up one dir, main page]

Skip to content

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.

8000

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from
Apr 18, 2022
Merged

Conversation

ethomson
Copy link
Member

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 the git_oid (like a type enum).

(This is broken out of #6191.)

ethomson added 14 commits April 10, 2022 15:56
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.
@ethomson ethomson force-pushed the ethomson/sha256_two branch from f75e253 to f882140 Compare April 10, 2022 20:14
@ethomson ethomson merged commit 3b52e5f into main Apr 18, 2022
@ethomson ethomson deleted the ethomson/sha256_two branch April 18, 2022 21:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant
0