-
Bug
-
Resolution: Fixed
-
High
-
None
-
None
-
None
-
None
Merge commit messages usually contain all commit messages from one branch. This includes the exact text from any Smart Commits included in the merge, causing all commands to be executed a second time.
i understand JIRA 7.1 included an improvement where duplicate time entries are ignored, in an attempt to solve the problem of merge commits containing time entries, but the #comment's are still added every time and any status changes (#ready-for-test, ...) are also carried out. The comments are not very critical, worst thing that happens is that it appears someone else adds the same comment I added, a few days after me (when they merge my commits into another branch).
The status changes are dangerous though: if a ticket has since been transitioned to another status which happens to allow transitions back to the Smart Commit's status, the ticket might suddenly be reopened without anyone noticing, and without any indication as to why.
My suggestion: add an option for BitBucket Server to simply ignore merge commits when checking for Smart Commits.
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[BSERV-8775] Merges should be ignored as Smart Commits
| Workflow | Original: Stash Workflow - Restricted [ 1445301 ] | New: JAC Bug Workflow v3 [ 3135494 ] |
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: Open [ 1 ] | New: Closed [ 6 ] |
| Workflow | Original: Stash Workflow [ 1400257 ] | New: Stash Workflow - Restricted [ 1445301 ] |
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
| Remote Link |
New:
This issue links to "devstatus › DevStatus - master - FECQ › bugfix- |
| Remote Link |
New:
This issue links to "devstatus › DevStatus CI - master › bugfix- |
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
| Status | Original: Needs Triage [ 10030 ] | New: Open [ 1 ] |
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.