Git打补丁常见问题

  往往觉得得到某个功能的补丁就认为这个功能我就已经成功拥有了,但是在最后一步的打补丁的工作也是需要相当谨慎的,甚至有可能还要比你获取这个补丁花费的时间还要多。看到好多同行遇到这个问题,且最近自己也花费近20天「获取,打,验证」一个特性功能的补丁。趁热总结一下,知识点可能不多,但是问题是相当棘手的。

$ 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 expect 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

$

第一步检测补丁有无问题

$ git apply --check xxx.patch

能检测出现的问题有以下几种例子:

1. error: cannot apply binary patch to ‘xxx‘ without full index line

xxx一般会是bin/png/gif等等二进制文件 具体的原因就是patch中有指明要打上xxx文件,但是这个文件并不包含在这个patch中,仅仅是有一个名字存在其中。遇到这个问题要重视。

2. error: core/java/android/provider/Settings.java: patch does not apply

出现这种一般会是补丁冲突,这种一般是强制打上补丁(使用--reject)后根据产生的*.rej文件来手动解决冲突。

3. warning: core/java/android/view/View.java has type 100644, expected 100755

出现这种警告一般是文件内没有冲突,但是文件的权限发生变动。一般没有影响。

第二步强制打补丁

$ git apply --reject xxx.patch

执行了这一步后会产生什么样的结果,我对第一步的冲突来对应说明。

1.这种问题一般是制作补丁的开发人员没有将二进制文件制作到patch中云,对于这种情况不会有任何的提示,因为patch中源资源文件都没有,Git也没有什么招术来解决。最好的方法是联系补丁提供者。

2.这种情况是由于git apply是对比补丁中前后几行代码,如果没有出现在目标文件中,那么这就是冲突。这个是比较经常出现的,对于这种情况会生成*.rej文件,可以find ./ -name *.rej找到这些冲突的补丁,手动打上就好。

3.可以考虑忽略。

目前就这些,遇到新的问题再补充。

时间: 2024-07-29 23:50:39

Git打补丁常见问题的相关文章

Git 打补丁流程

A. 使用git制作补丁时, 需要创建一个新的分支, 修改之后再提交只需要修改需要修改的文件, 并使用git -format-patch -M master 将当前的分支与主分支(master)进行比较, 会自动生成一个补丁文件, 此处不需要add 在切换到master 分支中就会看到那个补丁文件, 这与分支之间是独立的有一些出入. B. 在master分支上在创建一个新的分支并切换到那个新的分支上去, 使用git am 补丁 文件名 命令应用补丁, 之后提交修改 C. 切换到主分支, 合并新分

git常用命令+常见问题

目录 git常用命令 常见问题 git学习资料 git常用命令 推送至远程库 1.git init #本地git仓库初始化 2.git add . #将本地所有文件添加到暂存区 3.git commit -m "xx" #将暂存区文件添加到git仓库 4.git remote add origin [email protected]:michaelliao/learngit.git #和远程仓库做关联 5.git push -u origin master #推送至远程仓库 -----

git制作补丁Patch和应用补丁Patch

1 先找到指定的提交id,比如 cc451ef67a301003bbaf5bf616e08f1a3221268e 2 到git代码目录中,敲命令制作Patch git format-patch cc451ef67a301003bbaf5bf616e08f1a3221268e 3 命令执行完成后,在当前目录生成若干个.patch的文件 把生成的.patch文件打包上传到服务器上并解压出来(步骤省略) 4 在服务器上应用补丁Patch 清除之前的错误信息 git am --abort 应用补丁 gi

Git 打补丁----基于源码改动生成 patch 包的方法

git diff 生成补丁方法: git diff 本次提交前一次commit的序列号 本次提交commit的序列号 > xxx.patch #使用diff方法也可以将多次修改打出一个patch包来 git apply XXX.path git format-patch $ git format-patch HEAD^ //生成最近的1次commit的patch: git format-patch -1 同作用 $ git format-patch HEAD^^ //生成最近的2次commit的

git 打补丁,即git review之后需要二次修改并提交代码

假如代码已经push上去了,可是当review时,发现有地方需要修改,你可以继续在本地修改你的文件,之后git status查看修改的文件,然后git add修改的文件,此时不能直接git commit了,因为git commit之后会产生新的commit ID,而你想做的是把这次的修改与上次的修改合并到一起,所以这次要commit到之前生成的ID上边,在git中这样的操作叫做打patch.这里我只会用git GUI commit到上一次ID中: 1>     跟第一次修改一样进行git add

git的一些疑难点

一 .git reset,git revert,git checkout的区别和联系 主要参考:http://www.cnblogs.com/houpeiyong/p/5890748.html git reset.git checkout和git revert是你的Git工具箱中最有用的一些命令.它们都用来撤销代码仓库中的某些更改,而前两个命令不仅可以作用于提交,还可以作用于特定文件. 因为它们非常相似,所以我们经常会搞混,不知道什么场景下该用哪个命令.在这篇文章中,我们会比较git reset

Git 版本管理工具命令速查

转自:http://www.jb51.net/article/55442.htm 一. Git 常用命令速查 git branch 查看本地所有分支git status 查看当前状态 git commit 提交 git branch -a 查看所有的分支git branch -r 查看远程所有分支git commit -am "init" 提交并且加注释 git remote add origin [email protected]:ndshowgit push origin mast

GIT的使用中的问题处理

GIT 的常规操作 常规操作也是我自己平时常用的几个命令, 学自于 pro git 这本书中 git 配置文件 git的配置文件位置针对所有用户:/etc/gitconfig针对当前用户: -/.gitconfig 查看配置的方法 git config --list 修改配置的方法 git config --global user.name "wangyubin" (修改的是-/.gitconfig) git config --system user.name "wangyu

git的使用--不错的博客【转】

转自:http://www.cnblogs.com/wang_yb/p/3867221.html GIT 的常规操作 常规操作也是我自己平时常用的几个命令, 学自于 pro git 这本书中 git 配置文件 git的配置文件位置针对所有用户:/etc/gitconfig针对当前用户: -/.gitconfig 查看配置的方法 git config --list 修改配置的方法 git config --global user.name "wangyubin" (修改的是-/.gitc