Trying to understand patching for Dwm

[jb1277976_]

Hi,

I have no logs or anything i'm just trying to get an understanding.

So i'm using dwm and when i download a patch i use portage and about 8/10 it fails. I was advised about https://wiki.gentoo.org/wiki/Creating_a_patch basically getting clean code from the ebuild
creating a commit, patching it then git diffing to create a patch. now that works about 9/10 meaing about 3 out o 6 that just don't work.

Why does creating a new patch actually work ?

The only thing i can think of is that the diff i originally downloaded from the dwm website was patched against clean code and applies and if i have modified code already then it won't work.

I hope that makes sense and would like somebody to explain it.

~Joe B

[NeddySeagoon]

jb1277976_,

A patch looks like, its two hunks from my /etc/portage/patches/media-gfx/iscan-2.30.4.2/fixfunctiontypes.patch.

Code: Select all

--- a/backend/model-info.c_orig 2021-11-13 15:58:38.353143768 +0000
+++ b/backend/model-info.c      2021-11-13 16:05:35.995828068 +0000
@@ -301,7 +301,9 @@
  *
  *  \return  \c true if commands have been modified, \c false otherwise
  */
-bool
+
+/* Drop the bool here, to match the header  bool */
+
 model_info_customise_commands (const void *self, EpsonCmd cmd)
 {
   bool customised = false;
@@ -665,7 +667,7 @@
   return false;
 }
 
-bool
+/* Drop the bool here to match the hacck to the .h file bool */
 model_info_has_lock_commands (const void *self)
 {
   _model_info_t *self_ = NULL;

It contains a header, naming the file to be patched

Code: Select all

--- a/backend/model-info.c_orig 2021-11-13 15:58:38.353143768 +0000
+++ b/backend/model-info.c      2021-11-13 16:05:35.995828068 +0000

A location in the file to apply the hunk

Code: Select all

@@ -301,7 +301,9 @@

That says that the 7 lines at line 301 will be 9 lines after the hunk is applied.

Then there is three lines of context

Code: Select all

  *
  *  \return  \c true if commands have been modified, \c false otherwise
  */

The hunk will be rejected if they are not found,

Then the change.

Code: Select all

-bool
+
+/* Drop the bool here, to match the header  bool */
+

Remove one line and add three, so nett effect is to add two lines, as the location says.

Lastly there is three lines of context after the change.

Code: Select all

 model_info_customise_commands (const void *self, EpsonCmd cmd)
 {
   bool customised = false;

The hunk will be rejected if that isn't found too.
My example above shows a further hunk.

Knowing the above, the ordering of patches is critical. Another patch max have changed the contexts for this patch.
It may try to use the changes above for its own context.

Patching another area of the file so the the location is not correct will make patch emit a warning about an offset but the patch will still apply.

[Hu]

This is not specific to dwm, but shows up most often because of dwm's odd focus on requiring users to apply source code patches to get anything changed. Most projects would directly commit the really popular patches, and provide a compile-time flag to switch the patch's effect on or off. dwm instead posts the popular patches as an add-on download, and expects you to apply the patches you want enabled.

GNU patch requires a certain amount of context around the lines to change, and requires the line meant to be changed to match what is shown in the patch file, so that it does not apply the change in the wrong place. Consider the consequences if a patch was defined simply as: go to line 100, add this string, save, and done. What happens if you apply that to a file which gained 10 lines above line 100? Now your string is in the wrong place, which at best will fail to compile, and at worst will run with some obscure bug. To avoid this, GNU patch (and probably all other good patch implementations) require matching context, so that it can locate that now your string should be at line 110. If the surrounding context is too different, GNU patch will give up entirely, preferring to ask you to sort it out rather than let it guess wrongly.

Creating the new patch works because you (hopefully) adjusted correctly for the changed context, and provided that updated context in your regenerated patch file. Yes, if your patch mismatches relative to the code you want to patch, it will fail. dwm is particularly vulnerable to this because they push users to routinely apply multiple patches, and some patches may invalidate others. Also, some patches may require others, so applying them in the wrong order, or skipping one that you think you do not need, can cause a failure.

[GDH-gentoo]

Others gave the long version of the answer, but...

The only thing i can think of is that the diff i originally downloaded from the dwm website was patched against clean code and applies and if i have modified code already then it won't work.

... yeah, that.

[jb1277976_]

Thanks everyone!