Repository navigation
Converting a patch into a diff #47
Description
Hi!
I have a need to convert a patch into a normal diff, is there some functionality within this library that could facilitate that or do you have any recommendations?
I'd rather not parse the patch and then reconstruct it. I could parse out the header information and any trailing git version numbers at the bottom but I feel like this library already does most of that work.
Thanks!
Activity
bluekeyes commentedon Jul 19, 2024
I think right now your options are the two things you described: parse the patch and then format it again, or split out the diff section with some external logic.
The current structure of the parser makes it hard perform a split like this without parsing everything because it consumes the input as it finds matches. You also kind of have to parse every file fragment anyway to know for sure that a
--line is the marker for the patch footer and not part of the diff.I think even if there was a function that returned the diff part as a string, it would probably be constructed internally by parsing the whole input and throwing out the structured result. I'll think about it some more, but on a first pass I didn't have any good ideas for implementing that.
If you were willing to format a parsed patch, the
TextFragmentcan almost do this today (withHeader()andLine#String()), although not in a single method call. I could see adding better formatting methods to this and theFiletype, which would at least save having to re-write the printing code in each application that wanted this.neurosnap commentedon Jul 19, 2024
Thanks for the reply! If File or Line had a #String method so at least that structure was correct I would be happy with parsing the entire patch and doing some for-loops. Also happy to help implement it
bluekeyes commentedon Jul 22, 2024
I've started working on
String()functions for all of the parsed types. One note is that while they'll produce diffs that are semantically the same as the input (and will parse to the same objects), they probably won't match the literal bytes of the input - not sure if that matters for your use case or not.neurosnap commentedon Jul 22, 2024
Nope, I don't care if it is byte-for-byte identical. Thanks for your help!
bluekeyes commentedon Aug 11, 2024
The latest code on
masterprovidesString()methods for all of the parsed types. It seems to work correctly with my small test diffs, but please let me know if you see any issues using it with larger real-world patches.