[iforgotpassword]

That would change the commit hash, at least if you want it to survive a clone of the repo. Of you'd store it externally so that it would only be able to be shown in the webui then it's of limited use, but maybe better than nothing.

[macintux]

Specifically it could be exposed through the GitHub REST API without impacting the commit itself.

[xrisk]

I feel the commit data could be extended to include some metadata that isn’t used to compute the hash. GitHub could then make use of this data to populate whatever.

(Not sure if such a field already exists in the commit blob)

[Karellen]

> I feel the commit data could be extended to include some metadata that isn’t used to compute the hash.

That's not how git works.

[xrisk]

I’m somewhat familiar with how git works. In my understanding, a commit is just a blob combining the commit information and a tree blob, hashing them together to create a commit id.

This design doesn’t preclude the usage of additional information in the commit blob that isn’t used to compute the hash.

(Think for example how file access times do not affect its hash)

[Karellen]

If it's not part of the information that's hashed to create the commit id, it's not part of the commit. By definition.

[formerly_proven]

Git is a content-addressed object store, the address of any stored object is the hash of the object itself. So you actually can't stuff extra data into an object and not change its ID; this auxiliary data would need to go in a separate store indexed by object ID or a similar solution. The reason why file access times don't affect git hashes is because git does not store them.

[jwilk]

I think you want git-notes (or something similar):

https://git-scm.com/docs/git-notes

"Adds, removes, or reads notes attached to objects, without touching the objects themselves."