11–20 of 389 posts
I have never seen any dev searching for error messages in commit messages.
For the rest of the points (makes smarter, builds trust and compassion), if it's so worthy put it on the blog (like this blog post itself) so it can has a potential to reach some reach some audiance.
Should this go into a commit message, instead of an issue/ticket?
Should this go into a commit message, instead of an issue/ticket?
git log | grep
git show
Should this go into a commit message, instead of an issue/ticket?
I say yes. I like to keep information about the code as close to the code as possible. Issue trackers come and go, and even if you keep the same issue tracker around, how are you going to relate the change in the code to the particular issue down the road? FWIW, I also prefer READMEs to Wikis.
Unless you use Fossil :-P. Or for git/hg/svn/cvs/Folder - Copy(43), one of those ticket trackers that work with files inside the repository itself.
Should this go into a commit message, instead of an issue/ticket?
A great question! I’m still wondering why we all mostly use separate tools for tickets and version control (and knowledge base, and collaboration, and management/hiring, the list goes on), given we already know a lot about software development.
Code, commit logs, tickets, and project management are all part of the same repo with Fossil.
Should have been in a doc or wiki instead of commit message. I have never seen any dev searching for error messages in commit messages. For the rest of the points (makes smarter, builds trust and compassion), if it's so worthy put it on the blog (like this blog post itself) so it can has a potential to reach some reach some audiance.
In the article order: the screenshot is from a commit detail page. How often do you land on this page? You need to specifically click through. If you are in a commit list, the only thing that sets title-only commits and commits with description apart is an ellipsis link which practically blends in with the background. It is not very well integrated nor discoverable. Also I don't believe the commit descriptions render as MarkDown (unlike issues) which is also a shame as it feels like less a doc then. But I might be wrong on this. But even outside of GitHub, how many other UI/IDE plugins and other kinds of Git tools restrict commit display to just the title and put the description on the sideline? Most of them. I think this further leads to the currently low value of the commit message being searchable. Since it is exceedingly rare for good commit messages to exist, no one thinks to search them. People default to Google, when their own project's codebase/knowledge base could hold the answer to their query. I don't have much of an opinion on the commit message telling a story / having a human touch. I mean, it doesn't hurt I guess, but until _full_ commit messages become more "mainstream" (for a lack of a better word), they can be as human as they can, but they will live in solitude.
Should have been in a doc or wiki instead of commit message. I have never seen any dev searching for error messages in commit messages. For the rest of the points (makes smarter, builds trust and compassion), if it's so worthy put it on the blog (like this blog post itself) so it can has a potential to reach some reach some audiance.
The problem with that approach is that it doesn't survive as well as you'd like, because fixing a typo in a line would get you "ownership" of the line (since only the last person to change it is blamed). It's even worse in semi-major refactors due to moved/renamed files being treated as new....
Far better to have docs apart.
Should this go into a commit message, instead of an issue/ticket?
In a professional setting, companies usually want this information to live in the issue tracker. Mainly to provide insight to managers/other teams without looking at commit messages.
But it removes the information from the code: you now need to look at the issue tracker to make sense of changes, eg when looking at the history of a file, or with git-blame.
I'd argue that all relevant information that affects the code and architecture of the specific repo should live in commits. They should not only tell you what was changed, but also why; and provide enough context to understand the change in the scope of the repo.
All information that is not directly tied to the code, eg cross-repo/product/etc concerns can go in the issue tracker.
Of course this only works well with a `git commit --fixup` and squash + rebase / squash + merge workflow.
And with monorepos it also becomes a tooling problem.