←back to thread

577 points Delgan | 1 comments | | HN request time: 0.205s | source
Show context
b0a04gl ◴[] No.44347062[source]
i use git notes pretty heavily in my current role. started as an experiment to keep track of internal code reviews without flooding the commit message or making PRs for everything. i tag every commit with context what tickets it maps to, infra constraints, links to incident threads if it's a fix. all lives in the repo. this avoids the need to grep slack or jira just to know why a line changed. nce you start using it at scale, you realise how little you need the platform UI at all. we keep talking about reproducibility in builds, but never in intent. maybe this is where that starts
replies(1): >>44348157 #
smallpipe ◴[] No.44348157[source]
Shouldn’t that be the commit message ? Or is the goal to also link forward in time, such as “we realised this commit introduced bug #123” ?
replies(1): >>44348296 #
b0a04gl ◴[] No.44348296[source]
haha wait do you actually read long commit messages( more than a line) all the way through? like line-by-line, imo commit msg = tweet, git note = blog post.
replies(3): >>44348370 #>>44348380 #>>44350604 #
smallpipe ◴[] No.44348370[source]
In my line of work a bug could cost multiple millions. I do read them. I write long ones. I would love if my colleagues started writing longer ones too.
replies(1): >>44352918 #
1. Ayesh ◴[] No.44352918[source]
Me too.

Most of the times, the commit message is 10+ lines while the change itself is -1/+1.

We use GitHub for repo hosting and a separate issue tracker to coordinate changes. It bothers me a lot that GitHub UI doesn't render markdown for commit messages. We all write really detailed and nicely formatted commit messages, and had to work out a commit message sync so the issue tracker can display related commit messages in full Markdown glory.