Skip to content
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.

Already on GitHub? Sign in to your account

Use the extracted merkle library #2636

Merged
merged 4 commits into from
Nov 11, 2021
Merged

Conversation

mhutchinson
Copy link
Contributor

@mhutchinson mhutchinson commented Nov 9, 2021

The merkle library in this repo can be marked as deprecated after this. New clients would be better served by using the smaller module, especially for client-side code which will not need all the server-side dependencies that this repository has collected.

Checklist

The merkle library in this repo can be marked as deprecated after this. New clients would be better served by using the smaller module, especially for client-side code which will not need all the server-side dependencies that this repository has collected.
@mhutchinson mhutchinson requested a review from a team as a code owner November 9, 2021 17:28
@google-cla google-cla bot added the cla: yes label Nov 9, 2021
@AlCutter
Copy link
Member

Looks like a goimports might be needed

Copy link
Member

@AlCutter AlCutter left a comment

Choose a reason for hiding this comment

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

You still have references to github.com/google/trillian/merkle/hashers in here - the LogHasher i/f in that package is now/also in github.com/transparency-dev/merkle

@AlCutter
Copy link
Member

github.com/google/trillian/merkle/logverifier structs & funcs are now/also in the github.com/transparency-dev/merkle package too

@AlCutter
Copy link
Member

That last commit seems to have reverted a bunch of references back to the trillian merkle, was that intentional?

@mhutchinson
Copy link
Contributor Author

Yep, I figured the various merkle packages here (merkle, internal/merkle etc) should stay self-contained. If we break that self-containment we should probably do it with aliases to create forward references to the new locations, but that's a big job.

@AlCutter
Copy link
Member

Yep, I figured the various merkle packages here (merkle, internal/merkle etc) should stay self-contained. If we break that self-containment we should probably do it with aliases to create forward references to the new locations, but that's a big job.

Ah, yup, makes sense, ta

@mhutchinson mhutchinson merged commit 8f8d6d2 into google:master Nov 11, 2021
@mhutchinson mhutchinson deleted the merkle branch November 11, 2021 14:08
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.

2 participants