> Unless you are expecting devs to copy paste a tonne of info into commit messages, it's way easier to just put the god damn ticket number in the commit title.

Yes, that's what devs should do. Or link to an issue from the git provider. Commit messages shouldn't contain customer information, they should contain fine grained information why the change fixes a particular issue and other technical minutae.

What you doing here is conflating business information and technical information. Business knowledge has no reason to be in commit messages. The code base should be 100% understandable without specific knowledge about what customer wanted what. It would be a huge red flag for me to see those things talked about in the context of the commit messages as a regular thing.

I hate to break it to you, but code is usually written in support of a business objective and does not exist in a vacuum of technological purity... I say this as someone who's written everything from x86asm to python and everything in between for decades. If it really upsets your sensibilities to insert a reference to that business objective in a commit message then I don't know what to tell you...

A business objective is generally translatable to a use case, user story or requirement that can be understood without knowing "Mr. Smith from Company Thingamajig struggles to do x and is willing to pay sums of money to have it fixed". Your developers absolutely should NOT be knowing or dealing with business objectives.

As always there can be exceptions but if this is normal operating procedure for your company I would run far and fast.

> If you really need to commit something with no ticket

I'm of the opinion the only time this should ever happen is if it's a critical fix to allow ci builds to succeed. E.g. unit tests with hard-coded assumptions about the external world (current date etc.) that stop being true. Or errors in pipeline scripts that occur due to changes in a build agent.