• 
      

    Add a DiffSetting field for enabling/disabling interdiff filtering.

    Review Request #15021 — Created April 27, 2026 and submitted

    Information

    Review Board
    release-8.x

    Reviewers

    This introduces DiffSettings.interdiff_filtering, which controls
    whether the interdiff filtering logic wlil apply. At the moment, this is
    intended for internal use, but we may opt to include UI for controlling
    this so that users can toggle the display in the event of an issue with
    interdiffs.

    Interdiff filtering is always enabled by default.

    Unit tests pass.

    Tested this with an in-progress change for a new interdiff filtering
    algorithm.

    Summary ID
    Add a DiffSetting field for enabling/disabling interdiff filtering.
    This introduces `DiffSettings.interdiff_filtering`, which controls whether the interdiff filtering logic wlil apply. At the moment, this is intended for internal use, but we may opt to include UI for controlling this so that users can toggle the display in the event of an issue with interdiffs. Interdiff filtering is always enabled by default.
    438659a6ea45bb9d5c2c3f770429f1d0fd9f279a
    Description From Last Updated

    There's no test case for the negative case where diff filtering is turned off. Can we add one?

    david david

    Before we were just checking truthiness, but now we're explicitly checking None. I don't think we should have to worry …

    david david
    david
    1. 
        
    2. Show all issues

      There's no test case for the negative case where diff filtering is turned off. Can we add one?

      1. We don't really have any tests today that bridge the two. Let me look into how much of a pain that might be.

    3. reviewboard/diffviewer/opcode_generator.py (Diff revision 1)
       
       
       
       
       
       
      Show all issues

      Before we were just checking truthiness, but now we're explicitly checking None. I don't think we should have to worry about empty bytes here but just in case, do we want to still check truthiness?

      1. I'm not sure. I've gone back and forth since reading this comment. On one hand, I think technically None is more correct, since it signals "we don't have one" rather than "it's empty." Realistically empty diffs should not be present, but there's not going to be any harm if it's an empty string in this case (interdiff filtering will find no ranges and skip the logic).

        That said, we can also look at it as "if it's empty, do we want to bother filtering?" And in that case, we should check for truthiness.

        Since we were using truthiness before, I'll just revert back to that.

    4. 
        
    chipx86
    david
    1. Ship It!
    2. 
        
    chipx86
    Review request changed
    Status:
    Completed
    Change Summary:
    Pushed to release-8.x (f9448a4)