Repository navigation
Read binary patches (with no binary data) - #3923
ethomson merged 3 commits into
Conversation
Sorry, something went wrong.
Instead of skipping printing a binary diff when there is no data, skip printing when we have a status of `UNMODIFIED`. This is more in-line with our internal data model and allows us to expand the notion of binary data. In the future, there may have no data because the files were unmodified (there was no data to produce) or it may have no data because there was no data given to us in a patch. We want to treat these cases separately.
| #define parse_advance_expected_str(ctx, str) \ | ||
| parse_advance_expected(ctx, str, strlen(str)) | ||
|
|
||
| #define parse_advance_expected_const_str(ctx, str) \ |
There was a problem hiding this comment.
Is this distinction really required? To the best of my knowledge, most compilers convert strlen("CONST_STRING") to a compile-time constant anyway.
Sorry, something went wrong.
There was a problem hiding this comment.
Yeah, I think that's reasonable. I think that any compiler that anybody is likely to use will convert strlen("const") to a constant and for the person using MSVC 6.0, this isn't likely to be the slow part of reading patches.
Sorry, something went wrong.
When creating and printing diffs, deal with binary deltas that have binary data specially, versus diffs that have a binary file but lack the actual binary data.
|
Thanks for the careful eyes, @pks-t ! |
Sorry, something went wrong.
|
Looks good to me now, thanks 👍 |
Sorry, something went wrong.
When parsing a patch file, when we encounter a diff that was produced without --binary, we should include a binary patch that contains no data. This type of patch node is special, and cannot be applied, but it allows us to round-trip a patch file accurately.
git_diff_binary objects now indicate whether they contain data or not. They "contain data" if they were produced by us when SHOW_BINARY is set or when they are parsed from a patch file produced by git with --binary set. They do not "contain data" when they are parsed from a patch file that simply says Binary files ... differ.