But, like I mentioned above: bugs have many properties, can be grouped permanently or ad hoc... you either need to label the connection you make between the commit and the bug, or have bug modalities, otherwise these connections become meaningless / useless.

To flesh it out, let's suppose this (uninvented scenario, I literally opened JIRA on the last ticket I worked on, it's called "Jupyter wizard" and has to do with a TUI utility that allows one to configure Jupyter installation). There are multiple people interested in this ticket who work on the source code:

* QA tester (needs to verify multiple features of the wizard). * QA manager (needs to know the status of testing / communicate to the tester). * R&D programmer (needs to write the code for TUI). * R&D manager (needs to supervise the programmer).

Optionally, of course, the head of the R&D department and anyone under him / her might want to look at the issue and contribute as well as release manager, product manager, customer support...

All the people involved have a reason to tie different commits to this issue. The tester may add a new test checking whether users can install VNC for Jupyter. The QA manager may annotate the added test to be included in nightly CI runs. The programmer may add code that breaks the test and the programming manager may add code to hide the newly added feature behind a feature flag in order to prepare the code for the upcoming release.

If all these people will only be able to say "commit" x "ticket", then for everyone involved there will be a lot of white noise when they try to discover the relevant work done on the feature. In fact, it will be so much, that such pairing will become meaningless because the team across the hall will also refer to this issue because they are writing the TUI library to be used in wizards, the customer support will request documentation for the feature and documentation writer will have to add more commits, again, referring to the ticket, producing multiple versions of the said documentation conditioned on release version...

In the same way how JIRA asks users when linking tickets together: how they should be linked, the commits and tickets also need to be linked in different ways to explain the nature of the relationship.