Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Separately enumerate/split out some of the inputs to the lock's memo #508
However, as with all hash-matching schemes, it has the disadvantage that, if there's ever a mismatch, we cannot know why that mismatch occurred. And, if hash inputs can vary in ways that are non-obvious to users (like, say, the totally-not-visible-outside-the-code analyzer version that is incorporated into the memo), team members can find themselves ping-ponging hash changes back and forth with each other, and/or a CI server, with no idea what the problem is. That would rapidly turn such mismatches into a false alarm, causing people to ignore it. That would certainly undermine the overall UX of the system that we're going for, and possibly even a real aspect of system integrity.
Now, I do think the hashes have value. We could, for example, create a simple HTTP service that takes a hash and returns a solution for it, thereby obviating the need for solving. Or, more low-tech, just keep a history of solutions somewhere else on disk locally, memo-addressable, the hash provides a convenient addressing system in this respect. But we need to split out some of the information in the memo into separate, explicit fields in Gopkg.lock so that we can provide more detailed feedback users about what might be causing weird mismatches.
I don't have a specific plan on this yet, but I'll update the ticket when I do.