Git patching FAQ

Tag: git

Git patching FAQ

 

I often think that I have successfully obtained a functional patch, but I need to be cautious when patching the last step, it may even take more time than getting the patch. Many colleagues have encountered this problem, and they have spent the last 20 days "getting, typing, and verifying" A Feature Patch. To sum up, there may not be many knowledge points, but the problem is quite tricky.

 

 

$ Git apply-H

Usage: git apply [Options] [<patch>...]

 

-- Exclude <path> don't apply changes matching the given path

-- Include <path> apply changes matching the given path

-P <num> remove <num> leading slashes from traditional diff paths

-- No-add ignore additions made by the patch

-- Stat instead of applying the patch, output diffstat for the input

-- Numstat show number of added and deleted lines in decimal notation

-- Summary instead of applying the patch, output a summary for the input

-- Check instead of applying the patch, see if the patch is applicable

-- Index make sure the patch is applicable to the current index

-- Cached apply a patch without touching the working tree

-- Apply also apply the patch (use with -- stat/-- Summary/-- check)

-3, -- 3way attempt three-way merge if a patch does not apply

-- Build-fake-ancestor <File>

Build a temporary Index Based on Embedded index information

-Z paths are separated with NUL character

-C <n> ensure at least <n> lines of context match

-- Whitespace <action>

Detect new or modified lines that have whitespace errors

-- Ignore-space-change

Ignore Changes in whitespace when finding Context

-- Ignore-whitespace Ignore Changes in whitespace when finding Context

-R, -- reverse apply the patch in reverse

-- Unidiff-zero don't have CT at least one line of Context

-- Reject leave the rejected hunks in corresponding *. rej files

-- Allow-overlap allow overlapping hunks

-V, -- verbose be verbose

-- Inaccurate-EOF tolerate incorrectly detected missing New-line at the end of File

-- Recount do not trust the line counts in the hunk Headers

-- Directory <root> prepend <root> to all filenames

 

$

 

Step 1: Check whether the patch has any problems

$ Git apply -- check XXX. Patch

The following are examples of problems that can be detected:

 

1. Error: cannot apply Binary patch to 'xxx' without full index line

XXX is usually a bin, PNG, GIF, and other binary files. The reason is that the patch specifies the xxx file, but this file is not included in this patch, only one name exists. Pay attention to this problem.

 

2. Error: Core/Java/Android/provider/settings. Java: patch does not apply

In general, this is a patch conflict. This is generally caused by a forced patch (using -- reject) based on the generated *. rej file to manually resolve the conflict.

 

3. Warning: Core/Java/Android/View/view. Java has type 100644, expected 100755

This warning usually indicates that the file does not conflict, but the permission of the file changes. Generally, there is no impact.

 

 

Step 2 force Patching

$ Git apply -- reject XXX. Patch

What kind of results will be produced after this step is executed? I will explain the conflicts in the first step.

 

1. this problem is generally because the patch developer did not make the binary file to the cloud in the patch. In this case, there is no prompt, because the source resource file in the patch does not exist, git does not have any tricks to solve. The best way is to contact the patch provider.

 

2. This is because git apply compares several lines of code before and after the patch. If it does not appear in the target file, this is a conflict. This is often the case. In this case, the *. rej file will be generated. You can find./-name *. rej to find the conflicting patches and manually add them.

 

3. Ignore it.

 

At present, we have encountered new problems.

Git patching FAQ