Given a digital asset (source code, binaries, groups of files, images, videos, etc.), run a cryptographically-secure hash over the bits that comprise that asset, and use the hash as the version for that asset.
where 72e5e550d1835013832f64597cb1368b7155bd53 is the content hash.
Message
A clean, clear consistent commit log is an indication of a high-quality project.
It's also a great tool for users and maintainers alike as the commit log becomes the release notes, which is the main way that
people find out what features are in the project.
The first line of the commit message must be a concise and useful description of the change.
Prefix with case Id in brackets, if the change is not trivial. Create a case if necessary.
The message is often, but not always, the same as the case subject.
Start with a capital letter.
Do not finish with a period.
Use imperative mood (“Add a handler …”) rather than past tense (“Added a handler …”) or present tense (“Adds a handler …”).
If possible, describe the user-visible behavior that you changed (“FooCommand now creates directory if it does not exist”), rather than the implementation (“Add handler for FileNotFound”).
If you are fixing what is clearly a bug, it is sufficient to describe the bug (“NullPointerException if user is unknown”) and people will correctly surmise that the purpose of your change is to fix the bug.
If the contributor is not a committer, add their name in parentheses at the end of the message.
Read the messages of previous commits, and follow their style.
Inspired by Julian Hyde email on the Calcite mailing list (Check those commit messages please! at 1 June 2018 at 19:42)