That doesn’t get stored in git, you won’t be able to see that information on the clone of the repository you will be developing on locally.

Just to expand on that, I always say there are three audiences for the commit message:

1. The reviewer

2. Someone scanning commit logs for patches of interest

3. Archaeologists

Archaeologists are people a year, five years, 10 years down the road who are trying to figure out how the code got to be the way that it is, so they can feel confident changing it. (See also "Chesterton's Fence"[1].) Those people should not have to dig out the conversation from some random PR to figure out what's going on.

[1] https://news.ycombinator.com/item?id=30070757

> Those people should not have to dig out the conversation from some random PR to figure out what's going on.

Not knowing to look to an associated PR thread for a commit would be the equivalent of modern day archaeologists not knowing what "carbon dating" was.

A fairly common occurrence when looking at old commits is that any URLs mentioned are now 404s, and ticket numbers are for an issue tracker that no longer exists.

Isn't the PR exactly where you'd go to see that information, if you're an org that uses PRs to store that information?

Unlike commit msgs, which are immutable and stored with the code, Jiras/Githubs etc. are transient.

It's in the commit message, so it will get stored: https://github.com/obsproject/obs-studio/pull/5875/commits/5...

None of that is part of the Git repo, so any mirrors won't have the context.

It's in the commit message: https://github.com/obsproject/obs-studio/pull/5875/commits/5...