I'm not sure if you would consider this a bug; probably an improvement. I'll open it as a bug and see how long it lasts.

We use both Crucible & Stash; some teams only use Crucible for code reviews and some teams use Stash pull requests for code reviews. The Stash teams have also started used some of the enhanced things like locking down develop or master and requiring pull requests to merge to them.
The problem is the teams that use Crucible for code reviews are now doing the same thing - they create reviews via smart commits (+review), do their Crucible review, it gets approved, and then a pull request is used to merge their branch back into develop/master. Or a pull request is used to merge their commit to a release branch (think git flow here). Fisheye parses the commits and makes another review in Crucible when it encounters the +review again.

So there's some aberrant behavior here in my opinion.
1) Why is FeCru creating a new review when it sees the same commit hash go by again? Shouldn't it be smart enough to ignore the +review if it already processed that hash?
2) Or, can I have a checkbox/toggle in the Smart Commit configuration screen to not parse smart commits on merges? I realize some workflows may want them parsed on merges, but we do not, so it would nice if it were toggleable. A global toggle is fine.

-Kelly G. Schoenhofen