This issue required a fix in JIRA. As a result, the fix is dependent on the JIRA version connected to Bitbucket Server. Upgrade to JIRA 7.1.9+ to get the correct behaviour with merge commits.

Hi,

I haven't tested it yet, since I've been on holiday the past few days, but it seems like that would work. I didn't know about the blank line feature in Git, that'll definitely be helpful in the future, thanks!

Basically our commit messages (when we tried to use smart commits) contained <ticket nr> <command> always on the same line, one ticket per line, and merge commits would put all of our lines together in one line. we didn't use a 'title' or anything, but it seems like that would be the solution for us.

So again, thanks for the suggestion!

Kind regards,
Joris

Thanks joris vandermeersch,

We're looking at a potential fix for this issue for JIRA server. In the meantime, did Bryan's workaround do the job?

Steve.

Joris,

I'm one of the Bitbucket Server developers. While another team handles the actual smart commits functionality, and will need to be the ones who ultimately action this ticket, I just wanted to offer a quick workaround for you.

From the way your merge log looks, I'm going to guess you have commit messages like this:

CAR-5494
#comment added column
CAR-8509 #ready-for-test

(The exact breakup of the lines isn't super important; I'm guessing it's something like that, though.)

If you add a blank line before the first smart commit directive, git merge won't include anything after that in the merge log. This is a Git behavior, and outside the control of Bitbucket Server. Git calculates the "summary" of a commit message to be everything (including line breaks) until the first blank line. So a message like this would just show as "CAR-5494" in the merge list:

CAR-5494

#comment added column
CAR-8509 #ready-for-test

It's not my intention to imply you're "doing it wrong", or that getting the developers to change the way they write commit messages would be simple (or even necessarily desirable for your overall workflow). I just wanted to offer you a way around the behavior that doesn't need to wait for code changes.

Hope this helps,
Bryan Turner
Atlassian Bitbucket

Sure, below is one that caused a whole bunch of tickets to go from 'Closed' back to 'Ready for Test' and added comments to all of them. Notice also how multi-line commit messages have been turned into a single line, sometimes causing the commands to work on tickets they weren't even intended for in the first place.

This particular merge was from a colleague simply pulling in changes from another colleague into his own branch.

I doubt this is a bug, I think it would be best to just ignore all merge commits for the smart commit detection. Merges will always happen, and often cause the same commit messages to show up multiple times. On the other hand, I might need to actually use the same commit message a second time when for example I've fixed a bug, committed the fix with #ready-for-test, then our testers decide to reopen it and I need to fix it again, once again using #ready-for-test. In that case, the seemingly duplicate message should not be ignored, but this would not be a merge commit.

I can't really think of any examples where merge commits would need to be considered for smart commits, but I would happily be proven wrong!

Merge branch 'feature/CAR-6816-upgrade-to-jboss-fuse-6.2-jboss' into upgrade_to_fuse_621_r2

* feature/CAR-6816-upgrade-to-jboss-fuse-6.2-jboss:
CAR-7143 #comment Now loading locale on login, not afterwards, and using cookie to pass it onto ExtJS CAR-7143 #ready-for-test
CAR-8494 partial rollback #comment Removed the confirmation dialog for navigation, should now only show up for closing window and logout CAR-8494 #ready-for-test
CAR-8413 controller, properties, extjs code #comment Implemented keepalive (as in professionals website) to prevent this from happening CAR-8413 #ready-for-test
CAR-8413 refactored KeepAliveController to abstract functionality into shared internal class, so we can reuse it in backoffice
CAR-8413 moved dto to shared-internal because we're going to use it in the backoffice as well
code cleanup
CAR-6996 #comment Using '/' in the value caused the certificate check to use an url that was not accepted, causing an unpredictable answer to that request. Fixed by 'accepting' such urls and simply responding an empty string (indicating that no certificate exists) CAR-6996 #ready-for-test
CAR-5494 #comment Upload date is now red if evidence was uploaded while rectification was (re)closed CAR-5494 #ready-for-test CAR-8510 #ready-for-test
code cleanup
CAR-5494 fixed script
bugfix: set rectification reclosedate when reclosing instead of reopendate
CAR-5494 #comment Now keeping record of if evidence is uploaded while rectification is closed CAR-8513 #ready-for-test
CAR-5494 #comment adjusted column widths CAR-8511 #ready-for-test
CAR-5494 #comment added column CAR-8509 #ready-for-test
CAR-5494 CAR-8512 #ready-for-test
code cleanup
centralized/refactored date formats in backoffice

Cheers,
Joris

Hello, I am one of the developers who worked on the recent improvement to the smart commits feature.

Would it be possible for you to provide us with an example commit message for a merge commit that caused the commands a second time. If the message contains sensitive information you can create a support ticket so that you can provide it to use in a confidential manner. We currently attempt to some duplicate smart commits detection in merge commit messages so this information would be valuable in determining if that is working as intended or if you have uncovered a bug.

Cheers
Gene Taylor, Atlassian