See example git repository: https://bitbucket.org/pswiecicki/cruc-6806-dup-files-on-review-no-common-ancestry with the following ancestry tree (typical diamond problem):

$ git log --graph   --oneline
* f5ee7b6 added master
* 31b6c4d added master
* f90b59e added master
*   fd84373 Merge branch 'branchRight'
|\
| * 16dcba6 added right
| * 7f58924 added right
| * e04882e added right
* | 1efa376 added left 3rd
* | 1ee5e72 added left 2nd
* | 8c60043 added left 1st
|/
* 55b80b9 on master

(each commits modifies single file.txt file)
When creating review for changesets 1ee5e72 (middle commit on branchLeft), 7f58924 (middle commit on branchRight) and f90b59e (merged master) Crucible end up showing two separate files on review, see

This seem to confuse Crucible users, they consider this as a bug, in fact it seems related to CRUC-6568 but it is not.

We could think of a way to improve this. Few options:

• continue to show files separate but make it explicit that they come from different branches
• stop adding same file more than once, find youngest common ancestor and add it to the review (there should always be one for typical repositories with single commit graph). Perhaps also find oldest common descendant and add it too, if there is one. But this brings problem how to show this if there is no common descendant yet. users expects the rightmost version on file revision slider is the most recent version of the file, but there is no really newer/older relation between commits of no common descendant.
• stop adding same file more than once, visualise linear version slider as commit graph? Seems weird and unnecessarily overcomplicated