Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Read binary patches (with no binary data) #3923

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Sep 6, 2016

Conversation

ethomson
Copy link
Member

@ethomson ethomson commented Sep 2, 2016

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.

Edward Thomson 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.
#define parse_advance_expected_str(ctx, str) \
parse_advance_expected(ctx, str, strlen(str))

#define parse_advance_expected_const_str(ctx, str) \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this distinction really required? To the best of my knowledge, most compilers convert strlen("CONST_STRING") to a compile-time constant anyway.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
@ethomson ethomson force-pushed the ethomson/diff-read-empty-binary branch from 3572768 to adedac5 Compare September 5, 2016 17:27
@ethomson
Copy link
Member Author

ethomson commented Sep 5, 2016

Thanks for the careful eyes, @pks-t !

@pks-t
Copy link
Member

pks-t commented Sep 6, 2016

Looks good to me now, thanks 👍

@ethomson ethomson merged commit 9ad07fc into master Sep 6, 2016
@ethomson ethomson deleted the ethomson/diff-read-empty-binary branch January 13, 2017 12:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants