0

I ran the following command to apply a patch, and in the first attempt, it spitted a couple of errors saying patch apply failed for these files, and after making changes to those files, I ran the command again to see a whole lot of other errors.

git apply --ignore-space-change --ignore-whitespace patch-file

But I checked a few files and it looks like the patch was correctly applied, but why the errors? The following .rej and the source file doesn't help me debug the cause

// c.rej
      fi
     fi

-    if [ "$qcrild_status" = "true" ]; then
+    multisim=`getprop persist.radio.multisim.config`
+
+    if [ "$multisim" = "dsds" ]; then
         # Make sure both rild, qcrild are not running at same time.
         # This is possible with vanilla aosp system image.
         stop ril-daemon

// .c

      fi
     fi
  
        multisim=`getprop persist.radio.multisim.config`
  
        if [ "$multisim" = "dsds" ]; then
           # Make sure both rild, qcrild are not running at same time.
           # This is possible with vanilla aosp system image.
           stop ril-daemon
xyf
  • 664
  • 1
  • 6
  • 16

1 Answers1

0

The patch clearly says that we must remove this line:

-    if [ "$qcrild_status" = "true" ]; then

No such line appears to exist in the file to which this patch is applied.

The patch says that upon removing the line, we should add instead three replacement lines:

+    multisim=`getprop persist.radio.multisim.config`
+
+    if [ "$multisim" = "dsds" ]; then

Those lines are, apparently, already there. So this particular diff hunk is likely already in the version of the file that you have, and this patch—or this portion of this patch—should not be applied.

This, of course, is just a guess. This is the general problem with a patch: a patch says how to change some specific file—or some specific version of some specific file, at least—so that it becomes some other file, or some different version of that same file. But you might have a third version of the file, or you might already have the updated file. In this case, the patch won't apply, or worse, will apply when it should not apply.

The latter happens when, for instance, a patch simply says to add an extra copy of a line that already appears several times. For instance, suppose one version of a file says:

Just the place for a Snark.
Just the place for a Snark.

Suppose the edit—the patch—consists of instructions to find these two occurrences of this line, and add a third one:

 Just the place for a Snark.
+Just the place for a Snark.
 Just the place for a Snark.

When this patch is applied to the two-line version of the file, you get the three-line version of the file. When the same patch is applied to the three-line version, you get a four-line version. If the patch is applied a thousand times, you get a version of the file with more than 1000 occurrences of the line.

(Perhaps this makes it even more true? Or:

Perhaps it is just the note of the bird
   Of which one should always beware,
The bird called a Jubjub—have you heard of this word?
  —In a poem you'll find over there.

Yes, I'm missing the internal rhymes in the odd-numbered lines. Alas.)

torek
  • 448,244
  • 59
  • 642
  • 775
  • Ahh...so it makes sense that I'd complain about the patch not being *applied* after it's been already given how there have been modifications made to the files already and it won't recognize them hence the error. What's the general procedure around this though? if initially 2 out 10 patches fail, how do you only run the patch only for those 2 files in particular as opposed to all them which will error out? – xyf Mar 05 '21 at 17:15
  • It's best by far to get access to actual repositories with actual commits, but if that's not possible—if all you can get are patches—you can use `git apply --reject` and just manually comb through the rejections and, well, hope a lot. It's not a good system but it's all we had back in the late 1980s and early 1990s (pre-Git, using `patch`), and it *can* work. – torek Mar 06 '21 at 00:47