Unfortunately, I don't think your approach at taking the common part of source and destination as the directory and file name is going to work in all cases:

• If a file was added or removed, the source resp. destination will be /dev/null.
• Some revision control systems track renames and moves and output them as a diff section with different source and destination.

And also, you are again trying to fix 2 bugs in one review request. Please submit one review per issue you fix.

In D5110#96624, @kkofler wrote:

And also, you are again trying to fix 2 bugs in one review request. Please submit one review per issue you fix.

Hmmm..... the problem is here is that the two issues here are intertwined and trying to see if the hunk applies cleanly is meaningless if the code can't locate the file.

In any case, I will submit two separate reviews.....

In D5110#96623, @kkofler wrote:

Unfortunately, I don't think your approach at taking the common part of source and destination as the directory and file name is going to work in all cases:

Hmmm..... you are right. Actually the correct solution would be to use the m_info->depth so that it would hopefully handled by the method setDepthAndApplied. However, as this option (depth) should be provided by the user, it would require an additional parameter in kompareinterface.h in methods openFileAndDiff and openDirAndDiff, which would break binary compatibility of "Kompare/ViewPart". So I'm just trying to guess here which as you suggested wouldn't work in all cases.

I would appreciate your feedback in this.

• Some revision control systems track renames and moves and output them as a diff section with different source and destination.

I'm not aware of such RCS. :\ Could you please provide an example?

Well, I think that in the present case, a single review is acceptable, but it needs to work in all situations. Unfortunately, I don't think your current code satisfies this requirement.