-
Notifications
You must be signed in to change notification settings - Fork 9
Support fuzzy patch #6
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
Conversation
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your fix here and, although I've tried to, I cannot make a patch file that would break your implementation.
I have one consideration about this. If I use the patch file (see the non-matching line `YYYY')....
diff --git a/Jamroot b/Jamroot
index a6981dd..0c08f09 100644
--- a/Jamroot
+++ b/Jamroot
@@ -1,3 +1,4 @@
X
YYYY
+V
Z
... IMO it is also a fuzzy patch and should behave the same. I see that the library, for this use case, returns an error from the # validate before patching
section. Should we add the logic to the validation and fail? Is there any reason why it allows a fuzzy patch after the changed section but not before?
I see. I think it's because the hunk The original file starts at line 1 and is 3 lines size. The initial validation didn't detect the my patch because it only checked the first 3 lines, ignoring We need to change the patch applying, but also the initial validation. The question is, should we add an option to allow fuzzy patch? We are breakingthe original behavior with this patch. |
From my point of view:
|
Fair enough! I'll check the bug again. Thanks for reporting this new case. |
Signed-off-by: Uilian Ries <uilianries@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we accept fuzzy patches, it should we as an opt-in (using an option), by default it is safer for us to fail
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! Thanks a lot, @uilianries
I know there are lots of use-cases to test, but I agree we should go step by step and assume that everything is working if anyone has reported it... (my head is thinking about patches removing lines, patches substituting one line by another, adding more than one line, removing several,... 🔬 😅 ).
@jgsogo Thanks for reviewing!! 💪 |
Released |
thanks! I gonna restart that PR in Conan |
fixes #5
Should close conan-io/conan#5963 too