-
-
Notifications
You must be signed in to change notification settings - Fork 242
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
Save unmodified file as xxx.old when applying a patch #569
Comments
👋 Thanks for the idea! Please remember that this is an open source project - feature requests may or may not be implemented, and if they are, the timeline is unknown. If you need a guaranteed implementation or timeline, sponsorships are welcome! |
Generating your patches like this seems really risky. Let's say I have symfony/console as a project dependency and I have some modification to https://github.com/symfony/console/blob/7.0/SingleCommandApplication.php. If I have a copy of that file and generate a patch using the differences between my copy of that file and whatever composer installs, how will I ever know specifically what that patch contains? What happens if symfony/console changes SingleCommandApplication.php after I take my copy of that file? Also, isn't the end result of that process the same as if you just had a pile of files that you copied into place? e.g. you have Either way, this is probably not a workflow that I can support in the core plugin, but that doesn't mean you can't do it. Composer Patches 2.x is extensible. You could write a composer plugin that subscribes to one of the Patch events and copies files around however you'd like. If you write a plugin to do that, let me know and we can set up a third-party plugins page in the Composer Patches docs to point people to it. I'm going to close this issue, but feel free to reply if I've missed anything! |
@cweagans I see your point, thank you for the answer! Just to clarify: the overall flow comes from a project https://github.com/symplify/vendor-patches/ which essentially is a wrapper for your project and that simplifies the creation of patches. I'm only considering the special case when one needs to update an existing patch. I already wrote own bash script that generates the .old files (i.e. the originals) based on the patches, it handles my use case pretty well: symplify/vendor-patches#22 (comment) Of course the above only makes sense in a simpler cases, in anything more complex I would resort to maintaining an own fork anyway. |
I think there's some room to integrate more closely if that's the workflow you want to use. I just can't support it in the core plugin. Happy to answer questions if you decide to write another plugin to integrate this one and vendor-patches (or maybe even add the extra code to vendor-patches itself?) |
Verification
composer self-update
)composer update cweagans/composer-patches
)Is your feature request related to a problem?
Workflow for updating patches is currently relatively complex. One needs to backup the modified files, remove the patches from config, run composer install, backup unmodified files, copy modified files from backup, modify them and regenerate the patches.
Describe your proposed solution(s)
Generate xxxx.old for each file to be patched before patching.
Having a backup as xxx.old will allow to easily modify the file and regenerate the patch using https://github.com/symplify/vendor-patches/
Describe alternatives
Currently the only alternative is the manual process described in the problem section.
Additional context
I made a related comment in symplify/vendor-patches
symplify/vendor-patches#22
The text was updated successfully, but these errors were encountered: