Multiple JIRA issues keys in one commit message

[Darly Senecal Baptiste]

Hi, 

While committing a code changes with a JIRA issue number I can see the code changes in that specific issue. However, I want to add couple of JIRA issues in a commit message but see the changes in just one of the bugs. As now, I am seeing the same changes in both of the issues. 

Is there a way to make the commit changes being seen justs for the first issue key and not for the rest of the issues mentioned at the commit message?

Thanks

[Andre Borzzatto · Accepted solution]

It seems like it's not possible, unfortunately, according to this documentation:

• https://confluence.atlassian.com/display/Cloud/Processing+JIRA+issues+with+commit+messages

I think that you would have to create separate commits for the bug you want to have the message attached in the commit and for the other ones.

[JeremyKastner]

Boooo...Fogbugz can do it.

[Anh Nguyen]

You can do it now.  https://confluence.atlassian.com/bitbucket/use-smart-commits-298979931.html  . Scroll down to see "A single command on multiple issues". 

[Bronius Motekaitis]

By mentioning a single or mentioning multiple Jira issues in your commit message, you can transition Jira stories and do other neat things. To mention multiple issues, just line'm up, like, "PROJ-123 PROJ-456: Completed the two tasks."

https://confluence.atlassian.com/bitbucket/use-smart-commits-298979931.html#UseSmartCommits-Asinglecommandonmultipleissues

Old question, but it came up before the new, correct answer did. Hoping a little harmless SEO stuffing helps out  someone :)

[Nash]

I've a question -

I've a custom field which has multi select, it has a Value 1, Value 2 and Value 3.

I need to write a filter which would  pull 2/3 of the values but not a single value

What would be the best way to write this JQL

[Darly Senecal Baptiste]

As I seen at the answers and discussed with the team, we will use a workaround that we can mention to just one JIRA issue correctly and the others user as DEMO#1 in our SCM commit message. 

Thanks all.

[Andy Nguyen]

Hi Darly,

I'm aware of some users using -DEMO-1 (prepending a Hyphen), to avoid linking a commit to the JIRA issue DEMO-1. So the commit message may be like "not linking to -DEMO-1".

DEMO-1 won't appear as a link in Fisheye as well as in DEMO-1's Development Panel in JIRA. However, the commit is still silently linked and appears in the deprecated Source tab, if the tab happens to show up in the JIRA issue (not an usual case).

By that I mean, you can still use this workaround to some extent.

Cheers.

[gustavo_refosco]

Hi Darly,

As per your description I think you actually want to have a commit associated with only one of these issues, and not have any commit associated with the other issues, is this correct?

In fact as pointed by Andre it's not possible to ignore the other issue keys you put in the commit message, but I'd like to ask you the purpose of not having the commit associated with the other issues. At first I see a commit associated with one issue, and it may be associated with more than one, as in your case, but if you don't want to link the commit to every issue, I thought about linking the issues among themselves directly in JIRA, as per the Linking Issues document, and then performing the commit against only one of these issues.

Please let us know if you believe the above matches what you are intended to do.

Regards,

Gustavo Refosco

[Darly Senecal-Baptiste]

Gustavo, The reason is the Code Reviews. Sometimes some developers had a set of JIRA issues (more than one), that just require one changeset (or code commit). And by mentioning these issue key numbers in one commit message: (1) That commit will appear in every issue mentioned in the message and (2) Since the Crucible code review is based by a JIRA issue number AND by SCM's revision id, the code review will appear in all these issues and consequently, it might create confusion and conflict between code reviewers because for a JIRA issue, some activities is not complete. And closing/completing the code review for one issue can interrupt the code review for other JIRA issues

[Darly Senecal-Baptiste]

That's why I am more partisan of a code review linked to a JIRA issue instead of the commit revision number