this post was submitted on 20 Mar 2025
71 points (100.0% liked)
Programming
19177 readers
167 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
At work we always put an issue number (together with a short summary text) in the commit message. The the verbose explenation is done in the issue, where formatting, search and filtering is easier. However this creates a dependency to that issue system.
yeah, trying to convince our product owner to read commit messages wouldn't go smoothly in my team. Some of them love their tickets....
the dependency to the issue system is unfortunate though, I do miss a "decentralized issue system" doing what git does for version control that would just seamlessly integrate with git and have a nice web GUI for less technical folks.
That's called a mailing list
/s
god, I already struggle trying to find information in github issues, I can't imagine using email for this
You don't have to imagine it; you can browse the Linux Kernel mailing list!
I would hate to have to open Jira tickets to be able to understand code or code changes in Git history.
I guess it depends on the quality of the summary. And how usable your issue system is.
I'm sure I would continue to feel uncomfortable though, about the code and history itself not being self-describing. Issue systems change, become unreachable, etc.