"It's impossible to find out why a change was made" is a completely separate issue. Either the code is documented or it's not, completely polluting your history with JIRA tags isn't the answer - not least of all because like a sibling commenter said you're now forever tied to JIRA, or if you ever move off of JIRA, now get to choose between bringing JIRA tag information into the new ticketing system, or rewriting your entire git history again.

It's definitely a concern to rely on the ticket system, but the commit message and the comment can't (and shouldn't) contain every bit of info about a change.

Commit message: "Improved clarity and detail in error message"

Ok, that's obvious what's happening, and as a standalone change that's absolutely fine. But the question it doesn't answer is why did someone actually put that effort in?

If the commit message mentions a ticket, then you can go look that up, and now you can find out, for example: it was a ticket that was an unknown bug being experienced by one specific customer, and so the error message was being improved as part of tracking down the bug. You also see who the customer was, internally who reported/escalated it, how long this has been an issue for, and if the bug was found and eventually fixed or not.

I'd argue absolutely none of that belongs in comments in the code, and it's way too onerous for a dev to constantly put that level of detail into every commit message. It's a balance: it's only useful to lookup that info on a small fraction of commits; it takes a lot of time to figure it out when missing (especially if it was many months ago); and putting a ticket number in each commit message is very low effort.

The project has just moved to JIRA from Bugzilla. The original convention was to put the Bugzilla issue ID in commit comments, these IDs were carried forward when moving to JIRA so people can still search for them.

Yes, "let's tie our codebase to the choice of ticket system forever as a means to commit documentation"

You can have both. Also, let's not pretend developers are wholly committed to writing comprehensive commit messages. A ticket number is useful if the change was relatively recent. If the organization moves to a different tool, chances are they are well aware of the potential history they are leaving behind.

and... I've never yet been in a team/project where being able to track/view/find issue/code pairings from years ago was ever remotely useful or helpful. If it was something in the last few months, sometimes people could dig in and try to understand a bit more by asking relevant people.

Finding a 'bug' introduced by someone from 4 years ago who doesn't work there any more, then finding the particular ticket that spawned it... this has never been high on the priority list of anyone I've ever worked with.

As an architect working on maintenance & refactoring, I find regular value in being able to understand the context (issue tracker ticket) in which a commit was made.

Also more than mildly useful for devs doing porting work.

Commit comments are rarely substantive enough, and "asking relevant people" is nice but not an actual substitute for keeping meaningful records.

I can recall multiple times I've determined why the current logic in the code should be not simplified as part of refactoring or fixing a bug after tracking down the original ticket associated with a commit. That original ticket is quite often a bug report, and sure enough, there was actually a good explanation for why the code is written the way it is, which is almost never going to be captured in commit or inline comments. While having an associated unit test is arguably a better way to capture the reason for such code changes, there are many reasons that's far less likely to exist than a JIRA ticket or equivalent.

So people put the ticket number in the message and then don't write a useful commit message. Congratulations, you just added one roundtrip per commit to the slowest website in existence to every single time you want to look at git history.

Did I mention that you can't look at JIRA from a mobile phone?

This assumes that writing a ticket causes people to explain their rationale better than a commit comment does. That might be the case, but it often isn't because tickets are filed by developers themselves, or by PMs who just write tickets like: "A system requirement is that users be able to do X" without further explanation.

Or you just write sensible commit messages. Commits together with the messages should require as little out of band information as possible.

Bullshit. "Fix performance issue in listing page for customer support".

Which customer? Is it the same issue as the one this other customer is reporting? How does the support person know the fix has been released?

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.

If you really need to commit something with no ticket, just have a dummy ticket placeholder like DEV-0000.

99/100 it's just laziness on the devs part... It's way easier to add a ticket number than write super detailed commit messages, and every case of missing Jira numbers of seen, there has never been a detailed commit message in its place... /Rant over

> 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.

The best thing about cross-linking between Git and an issue tracker is that when you have multiple commits for one ticket (very common), they can all link back to one ticket. Having the extra context from discussion is useful, but obviously that can be summarised in the commit message. So being able to instantly get a list of commits that link to the one ticket is the really invaluable feature that I don’t know of any good way of doing another way.

I'm a big fan of this personally, but I've also lived with the experience of completely useless commit messages, so I understand both arguments. Here's the most recent commits for a project I'm working on:

Counts

Counts

Counts

Counts

Log entries

missing package json

missing package json

ttl in seconds

cache back on

Still, I'd rather try to convince people to write useful messages than hard bind my remote code repository to my system for managing work, and often times (but certainly not always), single line commits are self explanatory.