Read binary patches (with no binary data)#3923
Merged
ethomson merged 3 commits intomasterlibgit2/libgit2:masterfrom Sep 6, 2016
ethomson/diff-read-empty-binarylibgit2/libgit2:ethomson/diff-read-empty-binaryCopy head branch name to clipboard
Merged
Read binary patches (with no binary data)#3923ethomson merged 3 commits intomasterlibgit2/libgit2:masterfrom ethomson/diff-read-empty-binarylibgit2/libgit2:ethomson/diff-read-empty-binaryCopy head branch name to clipboard
ethomson merged 3 commits intomasterlibgit2/libgit2:masterfrom
ethomson/diff-read-empty-binarylibgit2/libgit2:ethomson/diff-read-empty-binaryCopy head branch name to clipboard
Conversation
added 2 commits
September 2, 2016 11:22
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.
src/patch_parse.c
Outdated
| #define parse_advance_expected_str(ctx, str) \ | ||
| parse_advance_expected(ctx, str, strlen(str)) | ||
|
|
||
| #define parse_advance_expected_const_str(ctx, str) \ |
Member
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.
Member
Author
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.
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.
3572768 to
adedac5
Compare
Member
Author
|
Thanks for the careful eyes, @pks-t ! |
Member
|
Looks good to me now, thanks 👍 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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_binaryobjects now indicate whether they contain data or not. They "contain data" if they were produced by us whenSHOW_BINARYis set or when they are parsed from a patch file produced by git with--binaryset. They do not "contain data" when they are parsed from a patch file that simply saysBinary files ... differ.