<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> A diff tells you what changed, but a commit message tells you why it changed. Why code changed is frequently the most important piece of information being sought when looking at code you didn't write. Links to merge requests and issues may help but they are less permanent and frequently describe the purpose of a collection of changes, or the business case for a change. The advantage of having this detailed information in the Git repository in the commit message is that it is available to everyone, is available locally and through any tool that is integrated with Git, and is transportable if the project is forked, or commits are shared upstream. ## Vision [Good commit messages](https://chris.beams.io/posts/git-commit) should be encouraged, celebrated and amplified by GitLab so that following Git best practices is the fastest and easiest way to get the job done. To achieve this GitLab should make commit messages a first class member of merge requests and code review. ## Further details This takes us down a path of adding features that allow people to rewrite history on the server very easily. This can create problems for inexperienced Git users who try to fetch from a ref that has changed. ## Proposal **Improve access to commit messages** – commit messages are currently buried in the commits tab of the merge request which has the effect of deprioritizing them and making it very easy to ignore them during code review. **Commenting on commit messages** – this should support short and long (multi-line) commit messages. We should support commenting on any line of the commit message so that as long descriptive commit messages become more common in a team, targeted feedback can be offered on specific lines of the message. ## Links / references