WuTheFWasThat
commented
7 years ago this comment is quite late, but, at some point the behavior changed to be consistently always double-counting. So the second state in your example should never exist now.
I use clones now a bit and agree not double-counting would be better behavior. I would implement it if we can come up with something simple and efficient
Suppose that X and Y are clones with 10:00 in each, and that Z is a common ancestor. I would be much happier if Z showed 10:00 rather than 20:00.
This seems pretty hard to implement. The only efficient way I can see is to keep a note about the duplicate entry (or an offsetting negative time entry) at the LCA of X and Y, which sounds terrible to deal with.
The current behavior seems weird. If I have:
And then I clone B as a child of C. This will lead to
Which looks good. But then if you delete row D (or add a new child of row C), you get
which is less good.