[ltbarcly3]

I question the value of commit messages at all. Sure, at some level you need a summary of what a change is trying to do, but we have that at 5 levels now and they are completely redundant. Generally there is a ticket in some system for tracking changes, whether it's Jira or Github itself or some other system. Then you have a PR/MR that is attached to a branch which you are trying to have merged. Then there are the commit messages themselves. These are all completely redundant to each other, and nobody in their right mind should want all of these at the same time. It's too many places to look for the same exact information, there's no reason to maintain it in more than one place.

Some truly awful standard for formatting commit messages, how to do something that has at best dubious value to begin with, is a fantastic way to give the appearance of work without the need for skill or ability or spending time trying to get useful work done, a true boon to incompetents and hangers on. It's also a great way to snipe someone's amazing work and put yourself in a position to critique them with 1/1000th of the effort of accomplishing something useful.

[etra0]

I value the commit messages in the context where you develop a tool that has to be run widely.

In particular, I had experience with Wine. Having useful commit messages allows you to do bisects and trace down regressions with more ease than cross-checking messages with some external ticket system, and when you have a lot of people contributing to a project it's easier to see what they're doing when they try to do a patch.

I also believe though, that it is good practice to help your colleagues when they do need to find an issue in a project where a lot of different people can work on.

[ltbarcly3]

This would boil down to merge level messages. Not all projects squash commits, so what you actually care about here are the mr/pr level messages, which might be approximated by the commit message on the merge commit, but actually probably will just say merge {branchname}. When you bisect with parent=0 you only see merge commits or ff directly against main branch.

Putting what im saying another way, in a project with pull requests, commit messages are redundant with the text typed into the pr and the comments on same. We should just carbon copy those onto the merge commit and forget per commit messages.

[wavemode]

I think Jira messages are generally written from a product perspective ("here's what we want") whereas PR's are written from an implementation perspective ("here's how we did it"). And then the PR description ought to just become the squashed commit message (at least that's how my current company does it).

[cardanome]

Code tends to live longer than projects management tools like JIRA. The version history should always be understandable from itself without access to external software. Not to mention that JIRA tickets should be based on concrete user stories while commit messages describe implementation details, they are different layers of concern. As for individual commit messages, you need to so the poor soul reviewing your MR knows what the hell you are doing.

Seriously, please think of the poor soul having to maintain you legacy code when the JIRA is long gone or the external contractor who doesn't even get access to it in the first place.

[ltbarcly3]

Then tooling should be set up to maintain the same information in multiple systems. I'm not saying that its not important to remember what people were trying to do, I'm saying the original theory for commit messages is completely nonexistent in modern development. People don't make single self contained commits directly to main branch. Since everyone uses some kind of pull request as the unit of merge, just keep the information on the mr and copuly it to the merge request message.