• 
      

    Fix appending a specified newline type to a multi-byte-encoded diff.

    Review Request #11764 — Created July 31, 2021 and submitted

    Information

    DiffX
    master

    Reviewers

    When writing a diff to a file section, we always ensure it ends in a
    newline. There's some work that's done to ensure content and newlines
    are in the right encoding and the BOM stripped, and this didn't work
    quite right when working with a specified newline type, as opposed to
    guessing a type.

    The result was that, for multi-byte-encoded diffs, we could append a
    newline with a BOM, breaking the content.

    This logic has been cleaned up to ensure we always encode and strip BOMs
    at the right time.

    For additional reliability and performance, we also no longer split
    content into lines unnecessarily. If we're not indenting, we just return
    the content as-is instead of splitting into lines and writing them to a
    stream first.

    Unit tests pass on Python 2 and 3.

    Summary ID
    Fix appending a specified newline type to a multi-byte-encoded diff.
    When writing a diff to a file section, we always ensure it ends in a newline. There's some work that's done to ensure content and newlines are in the right encoding and the BOM stripped, and this didn't work quite right when working with a specified newline type, as opposed to guessing a type. The result was that, for multi-byte-encoded diffs, we could append a newline with a BOM, breaking the content. This logic has been cleaned up to ensure we always encode and strip BOMs at the right time. For additional reliability and performance, we also no longer split content into lines unnecessarily. If we're not indenting, we just return the content as-is instead of splitting into lines and writing them to a stream first.
    f4462b3b23783d4cac9abfb914d626825172761d
    david
    1. Ship It!
    2. 
        
    chipx86
    Review request changed
    Status:
    Completed
    Change Summary:
    Pushed to master (6246b15)