# UKAEA RSE Team Journal Club: 2024-03-14

:::info
- **Location:** B24-2-18
- **Date:** 2024-03-14
- **Article Link:** https://trunk.io/blog/git-commit-messages-are-useless
- **Agenda** *TODO*
1. Brief intro `2 min`
2. Discussion `43 min`
- **Participants:**
- Matthew B
- James P (scribe)
- Dan S
- Chris M
- Sanket G
- Kristian Z
- Adam P
- Harry S
- Matt F
- Aby A
- John N
- Kingsley C
- Jez S
- Callum H
- **Host:** Matthew B

:::

## Brief Intro

The overall case that commit messages are useless (and even harmful) is essentially as follows:

1. They are just local save points for an author, and therefore don't have meaning for anyone except the author, and oftentimes they aren't even relevant for the author.
2. You don't need to "show your work" and what actually matters is what gets built (the code is the source of truth)
3. Engineers implicitly know that they are "noise" and tend to ignore them anyway, which leaves to bad practices emerging. The analogue is that if you don't trust CI and it always fails, you will learn to ignore it.
4. These meaningless messages cost engineers a lot of time which is effectively a waste.
5. Engineers would be much better served by an "auto-save" feature like you get in the modern "shared online document" model.
6. Commits on your main branch should always work, and if you include all intermediate commits, it is likely things will be broken at many of them.

Some points to consider for discussion:

- Are there any cases or counter points to the assertion that commits can never be useful and are always just "showing your work"
- There is a big assumption here that everyone is working in a "trunk-based" manner. Presumably, these points don't hold so well in other workflows, e.g. in cases where there is a solo developer (often the case in research software). In those cases, the researcher might find their commit messages helpful?
- As the same time, they probably just need an auto-save functionality for their code?
- The point about the main branch only having working commits is mitigated somewhat by filtering. Thoughts?

## Discussion

- SG: Local save points is similar to vscode's timeline feature
- CM: Showing your work is useful for yourself
- MF: for example finding out where something broke by bisecting history
- JN: The suggested way of working may well be effective, but other strategies can also work
- SG/HS: Using a semi-linear process you can have a main branch with empty merge commits doing the roll of what the article claims squash committs do
- HS: Squashing prevents documentation of boy scout fixes as they won't be documented in the MR
- JN: The authors suggestion leads to chaining of MRs, which is organizationally problematic
- An MR description is a fundamentally differentformat to a commit message
- DS: The value from a MR is the discussions which happen therein, and the record of the ordering of the comments made and the commits added to the MR
- DS: The author seems to be working on a project where distinct changes are judiciously delineated into seperate MRs, but that can result in things which are related being artificially seperated, reducing contextual information
- JS: GitHub/Lab themselves become important sources of information (MR discussions, issues, etc.)
- DS: It is generally possible to transfer between GitHub/Lab but it is not clean/nice as there is not a 1-to-1 mapping between their systems
- CM: We are dependent on these platforms anyway for eg issues (GitLab is itself open-source at least)
- JN: Squashing makes git blame less useful, as you lose information about both who made a specific commit and what the intention of it was
- AA: Commit messages can be useful for people who don't have access to the developers (eg salespeople) to aid clients
- MB: Ideally this problem would be addressed by formal documentation
- CM: Autosave would be a hinderance as development is not always done in a logical order. You can then order it into commits in a way that is sensible
- JN: Autosave, in general, is a very useful system
- HS: There's an alternative system called JJ which does have an autosave-via-amend feature
- MF: You can use features like amending and staging. Comming to a commit forces you to take stock of your intentions
- MF: AUtosaving may be a more reasonable approach for live collaborative coding (eg vscode's liveshare)
- HS: Some tools can autoformat commit messages, or use them to generate documentation or other information
- Unanimous disagreement with the article