You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When fetchpatchsorts hunks, it can move hunks that change a file before the hunk that creates the file. This can cause the patch to fail to apply when patch attempts to modify a file that doesn't exist yet.
Gets written to the Nix store like this; note the hunks which modify m4/fp_ld_supports_response_files.m4 have been moved before the hunk that creates it, an issue not present with the original commit ordering.
This reordering is meant to make fetched patches more robust to changes in the source URL, but in some cases it can break the patches and make them unusable. There is also no mechanism in nixpkgs for disabling this behavior. Introducing an option to disable this sorting would be very useful.
Describe the bug
When
fetchpatch
sorts hunks, it can move hunks that change a file before the hunk that creates the file. This can cause the patch to fail to apply whenpatch
attempts to modify a file that doesn't exist yet.For example, this patch URL:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9897.patch
Gets written to the Nix store like this; note the hunks which modify
m4/fp_ld_supports_response_files.m4
have been moved before the hunk that creates it, an issue not present with the original commit ordering.GHC Merge Request 9897
Additional Context
This reordering is meant to make fetched patches more robust to changes in the source URL, but in some cases it can break the patches and make them unusable. There is also no mechanism in
nixpkgs
for disabling this behavior. Introducing an option to disable this sorting would be very useful.Related Issues
fetchpatch
silently strips binary sections #204320The text was updated successfully, but these errors were encountered: