Bug report: Show changes include revisions which are not selected

[László M.]

Bug found in version 1.9.7 (and earlier versions up to 1.8.0 also.)

Simple example to reproduce the bug:
- preparations:
You have at least 3 revisions affecting the same file named: rev1, rev2 and rev3 (order of revisions is important, rev1 being first, rev3 being last revision).

1) Click on Show log
2) Select only revision rev1 and rev3
3) Click on Show changes

- expectation:
You would only see the changes to that file made in rev1 and rev3, modifications of rev2 should not show up.

- result:
The changes will include the modifications made in revision rev2 even though it was NOT selected.

[Stefan]

On Tuesday, October 17, 2017 at 3:44:21 PM UTC+2, László Milu wrote:

Bug found in version 1.9.7 (and earlier versions up to 1.8.0 also.)

Simple example to reproduce the bug:
- preparations:
  You have at least 3 revisions affecting the same file named: rev1, rev2 and rev3 (order of revisions is important, rev1 being first, rev3 being last revision).

1) Click on Show log
2) Select only revision rev1 and rev3
3) Click on Show changes

- expectation:
  You would only see the changes to that file made in rev1 and rev3, modifications of rev2 should not show up.

how would that even work?

Imagine one line that got changed in r1, r2 and r3:

r1 : #this is a normal line
r2 : #this is another normal line
r3 : #this is another line

what would you show now as the diff between r1 and r3 but not r2? That doesn't make any sense.

If you select r1 and r3, you get the diff between r1 and r3, that includes all the changes in between.
Anything else doesn't make sense.

If you still think this would make sense, imagine a diff between r1 and r5000 without showing all diffs between r2-r4999...

Stefan

[hocke...@gmail.com]

I brought up a wrong example, but let me give you another example then, where this behaviour seems counter-intuitive.

Again 3 revisions like last time, but only r1 and r2 affecting the file I'm viewing, r3 contains changes in some other files only.
Again, you select r1 and r3 and go Show changes.
r2's changes will be displayed, even though that's not required to be displayed in order to avoid conflicts, because no other revisions after that (which I selected) modify that file.

Also, with merging (excluding r2), it merges in the expected way, without applying the changes in r2, even if it does end up giving a conflict in the end.
So it is actually implemented there already, is there a chance to get this feature anytime in the future for viewing changes based on the "merging" behaviour?

[Stefan]

On Wednesday, October 18, 2017 at 2:08:32 PM UTC+2, László Milu wrote:

I brought up a wrong example, but let me give you another example then, where this behaviour seems counter-intuitive.

Again 3 revisions like last time, but only r1 and r2 affecting the file I'm viewing, r3 contains changes in some other files only.
Again, you select r1 and r3 and go Show changes.
r2's changes will be displayed, even though that's not required to be displayed in order to avoid conflicts, because no other revisions after that (which I selected) modify that file.

Again, you've selected r1 and r3, so the diff is shown between those two revisions.

 

Also, with merging (excluding r2), it merges in the expected way, without applying the changes in r2, even if it does end up giving a conflict in the end.
So it is actually implemented there already, is there a chance to get this feature anytime in the future for viewing changes based on the "merging" behaviour?

Doing a merge and handle conflicts just to show a diff is not something that I would implement. Sorry. Not just because it would fail in anything but simple situations but also because it would be very, very confusing for users to see such a "diff" - it wouldn't be a real diff anymore.

Stefan