We have been facing similar issue like Aaron jensen faced. As a part of decomm of Jira server (EOL of server license), we migrate one project from Jira server to Jira data center with new project key but there was old project key ref were there in commit in user's Bitbucket repo so after migration, it breaks Jira link if user try to click on it

Thank you to give priority to add this feature in Bitbucket

Another use case: we just migrated our Jira instance to another instance. The old Jira and new Jira both had a project with the same key. When our project was migrated, it got a new key. We now have a repository full of commits with the old key that link to tickets in the new Jira that are completely unrelated. This actually happened with three of our Jira projects, so now we've got commits scattered across many of our repositories that contain links to unrelated tickets.

+1

I think that git notes provide an ideal backend for this.

I agree.  We have been using Git Notes to store metadata like this for a couple years now, and have begun storing Jira issue keys in Git Notes as well.  While we've got some custom reporting tools around this data, it would be much cleaner if Bitbucket's own Jira integration would leverage this data.  Another advantage of Git Notes is that their history is also captured in Git, should you want to see what the notes value was before, and who changed it and when.

Under development, the Jira issue can contain a link to branches. It would be great if a link to commits can be manually added. 
The commit message would do this automatically, but with a commit edit field you could add multiple commits to a Jira issue, and remove them. This should then be reflected on the Bitbucket side. 

Just ran into the problem of an incorrect key put in a commit message from several months back, with no safe way to rebase and rewrite the message.

Really, the commit message shouldn't be the single source of truth for related Jira issues. The process should be:

1. Commit is pushed to Bitbucket
2. Bitbucket scans commit message and collects Jira issue keys
3. Bitbucket checks keys for validity (BSERV-2470) and adds them to a table if valid, including from multiple instances (BSERV-10537)
4. Triggers to Jira and related systems are fired as necessary for each new issue added to that list

Users with Repo Admin/Write permissions can then add or remove Jira issues manually (and via APIs). This would also fix the problem of multiple Jira instances as users could remove the links that aren't relevant.

+1

Related to JSWSERVER-14378.

I recently migrated the version history of a project from a non-Git system to JIRA and Bitbucket Server. The old commit messages referred to issues in the old bug tracker but JIRA assigned its own issue keys. To make JIRA display the Git commits that relate to each issue, I ended up appending the JIRA issue keys to the commit messages after I converted the history to Git. However, some of the old commit messages refer to issues in another project that has not been converted yet, so I don't know what their JIRA issue keys will be. When that project is eventually converted, I will not be able to add link the Git commits to the resulting JIRA issues without rewriting history, which cannot be done with only git filter-branch because we now have pull requests, comments, and build statuses in Bitbucket Server.

kostmo wrote:

I think that git notes provide an ideal backend for this.

 git notes would be easier to script than a new REST API.

If a Git commit message refers to the wrong JIRA issue EXAMPLE-123 and I want Bitbucket Server and JIRA to disregard that reference, the git-notes blob could perhaps say "EXAMPLE-123 #unrelated" or "EXAMPLE-123 #ignore", using a keyword syntax like in smart commits.

We have linked wrong Jira issue Id to another Jira Item but after committing unable to edit the bug id. I think better to have an option to edit the link after committing.