v0.5.1

Improvements

• Relax requirements for mail-formatted patch headers (#20)

Fixes

• Fix parsing for file names with spaces (#24)

v0.5.0

Improvements

• Remove email decoration ([PATCH], re:, etc) from patch titles in ParsePatchHeader (#17). Any content removed in this way is stored in the SubjectPrefix field of PatchHeader.
• Remove email trailers (content after a --- line) from patch bodies in ParsePatchHeader (#19). Any content removed in this way is stored in the BodyAppendix field of PatchHeader.

v0.4.0

API Breaks

• Rename PatchHeader.Message to PatchHeader.Body for clarity.
• Remove the PatchDate type and use a plain time.Time instead. Parsing headers now returns an error when a date field uses an unsupported format.

Improvements

• Return a conflict error if the source still has content left after applying a patch that deletes the file.

Fixes

• Correctly parse single-digit unpadded days in ParsePatchDate.

v0.3.0

Add the ParsePatchHeader function and related types for extracting commit information from the preamble string returned by the existing Parse function. It currently supports the most common header formats generated by Git and can also parse similar headers even if they contain some unknown fields.

Improvements

• Add a top-level Apply method for convenience.
• Configure GitHub Actions for testing and linting

v0.2.1

Fixes

• Fix patch application when the amount of data after the last fragment is larger than the internal buffer

v0.2.0

Introduce the Applier type for applying binary and text patches. Like parsing, it is well-covered by unit tests, but not extensively tested with real-world patches. Text patches can only be applied in "strict" mode, where the content and positions in each fragment must match the source exactly. This restriction may be relaxed in future releases.

API Breaks

• Remove the LineReader type. While v0.1.0 introduced this type, it did not appear in any signatures.

v0.1.0

This is the initial version of the library. It supports patch parsing, but not application, and has not been tested extensively with real-world patches. The exported types and API are likely to have only minor changes in future versions, but no guarantees are made at this time.