Skip to content
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

Add support for patchset/patch/hunk string representation #23

Open
GoogleCodeExporter opened this issue Apr 18, 2015 · 3 comments
Open

Comments

@GoogleCodeExporter
Copy link

What do you want to do?

Print the representation of a parsed patch, for instance to split a large 
patchset in one patch per patch file.

How to test if it works as expected? Please describe step by step.

Given a PatchSet object, repr(PatchSet) should return a string that should be 
the same  (or almost the same) as the original parsed file.
Then for each Patch in the patchset, repr(Patch) should return a string that 
should be the same (or almost the same) as the original Patch in the parsed 
file.
Then for each Hunk in a patch, repr(Hunk) should return a string that should be 
the same  (or almost the same) as the original Hunk in the Patch in the parsed 
file.

It is OK if the line endings do not match exactly (i.e. hunkends may be 
ignored) and default to Posix, and it is OK if the repr is not exactly the same 
as the original one, but a good enough one.

Attached is a proposed patch with some tests, based on the latest HEAD @ r196



Original issue reported on code.google.com by [email protected] on 28 Mar 2013 at 11:00

Attachments:

@GoogleCodeExporter
Copy link
Author

Thanks for the patch. Dumping the output is useful. I surprised to realize how 
obsessed I was with parsing patches that completely missed the point that 
dumping parsed data is also very useful for debugging and checking that parsing 
is ok.

As for __repr__ and __str__ - I don't think it will be a useful representation. 
Accidentally type a name in console and you'll get several pages output. For 
the patch, I'd prefer a diffstat output - it is more informative, but can still 
be huge.

How about .dump() method instead? Or maybe you have a better name in mind?

Original comment by [email protected] on 29 Mar 2013 at 5:52

  • Added labels: Component-API

@GoogleCodeExporter
Copy link
Author

Well, in keeping with your approach to naming things in the code elsewhere, you 
have a fromstring() function already, so I named these tostring() 
The attached patch is updated to reflect this

Original comment by [email protected] on 29 Mar 2013 at 9:48

Attachments:

@pombredanne
Copy link

@pombredanne : pinging myself... Since I did enter that one on Googlecode

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants