Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

WIP: HashFromNode and VerifyDepTree methods #955

Closed
wants to merge 16 commits into from

Conversation

karrick
Copy link
Contributor

@karrick karrick commented Aug 4, 2017

What does this do / why do we need it?

HashFromNode creates a cryptographic digest (using SHA-256) of the directory rooted at the specified pathname. This can be used to address #121.

VerifyDepTree verifies the dependency tree against a map of known dependencies, along with file system nodes that were not expected to be found.

What should your reviewer look out for in this PR?

Function signatures do not exactly match what @sdboyer requested.

Do you need help or clarification on anything?

Which issue(s) does this PR fix?

These functions were requested in order to address #121, however might serve to address #944 as well.

@karrick karrick requested a review from sdboyer as a code owner August 4, 2017 21:04
@googlebot
Copy link
Collaborator

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.


  • If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
  • If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
  • In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

@karrick
Copy link
Contributor Author

karrick commented Aug 4, 2017

I signed it!

@googlebot
Copy link
Collaborator

CLAs look good, thanks!

@googlebot googlebot added cla: yes and removed cla: no labels Aug 4, 2017
@karrick
Copy link
Contributor Author

karrick commented Aug 4, 2017

When I was developing in my own fork, I had to change the internal exports to point to my own fork's copy: s|golang/dep|karrick/dep|g. The final commit before I submitted the PR, 27c0c77, changes all of the internal imports back to golang/dep.

I'm not certain why that particular commit is being shown as not included, but it's causing the build tests to fail, because the final commit is necessary to change the internal imports back to the original directories.

@karrick
Copy link
Contributor Author

karrick commented Aug 4, 2017

Looking at the Details from continuous-integration/appveyor/pr output, I recognized that I had omitted changing one of the internal import statements back to golang/dep. I fixed that, performed an additional audit of all the files in karrick/dep master to ensure no other instances were found, and pushed the commit to karrick/dep master, but before Travis CI build finished.

I would like to force kick off a new build of continuous-integration/appveyor/pr to verify it passes, but am unsure how. Instead, I plan on waiting for all of the other tests to finish, then if the failed test has not automatically executed, then I will push a small change to karrick/dep master, in hopes of kicking off a new build and tests.

@karrick karrick closed this Aug 4, 2017
@karrick
Copy link
Contributor Author

karrick commented Aug 4, 2017

Closed this PR, and will open a new one after I add a few more tests.

@sdboyer
Copy link
Member

sdboyer commented Aug 4, 2017

When I was developing in my own fork, I had to change the internal exports to point to my own fork's copy: s|golang/dep|karrick/dep|g

yeah, this is one of those annoying things. the standard practice (or at least, what i do) is to just set up my own fork as an alternate remote, then work on it directly in the canonical location on GOPATH.

IOW:

[~/w/go/s/gi/gol/dep] git remote -v
origin	git@github.com:sdboyer/dep (fetch)
origin	git@github.com:sdboyer/dep (push)
upstream	git@github.com:golang/dep.git (push)
upstream	git@github.com:golang/dep.git (fetch)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants