尽管本身Linux命令里有diff和patch两个命令可以生成patch和打patch。但是有两个缺点值得注意:
1. 对单个文件或者多个文件,diff和patch这两个文件比较方便。对于git这种以project为单位的修改,尤其是涉及到多个文件夹下的多个文件的改动时,就很不方便
2. 无法保存commit的信息。
因此,推荐大家使用git的format-patch和am命令进行生成patch和打patch,用此方法获得的patch其实就是commit里提交的code修改以及commit信息。有如下好处:
1. 对于git这种以project为单位的修改,尤其是涉及到多个文件夹下的多个文件的改动时,非常方便,能够记录所有的改动(添加,修改,删除文件等)
2. 可以保存commit信息。
3. 能够灵活的获取patch。可以获取任意两个commit之间的patch集。
使用方法(直接给一些examples):
git format-patch
$ git format-patch HEAD^ #生成最近的1次commit的patch
$ git format-patch HEAD^^ #生成最近的2次commit的patch
$ git format-patch HEAD^^^ #生成最近的3次commit的patch
$ git format-patch HEAD^^^^ #生成最近的4次commit的patch
$ git format-patch <r1>..<r2> #生成两个commit间的修改的patch(包含两个commit. <r1>和<r2>都是具体的commit号)
$ git format-patch -1 <r1> #生成单个commit的patch
$ git format-patch <r1> #生成某commit以来的修改patch(不包含该commit)
$ git format-patch --root <r1> #生成从根到r1提交的所有patch
案例
[root@x86builder jss]# git clone https://git.centos.org/rpms/jss.git
[root@x86builder jss]# git checkout imports/c8-stream-10.6/jss-4.7.3-1.module+el8.3.0+8058+d5cd4219 -b 8.3
[root@x86builder jss]# get_sources.sh
[root@x86builder jss]# ls
SOURCES SPECS
[root@x86builder jss]# ls SOURCES/
jss-4.7.3.tar.gz
应用上patch不编译 不检查依赖
[root@x86builder jss]# rpmbuild -bp SPECS/jss.spec --nodeps --define="_topdir $(pwd)"
正在执行(%prep):/bin/sh -e /var/tmp/rpm-tmp.LmrTXZ
+ umask 022
+ cd /root/work/build/centos/jss/BUILD
+ cd /root/work/build/centos/jss/BUILD
+ rm -rf jss-4.7.3
+ /usr/bin/gzip -dc /root/work/build/centos/jss/SOURCES/jss-4.7.3.tar.gz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd jss-4.7.3
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ /usr/bin/git init -q
+ /usr/bin/git config user.name rpm-build
+ /usr/bin/git config user.email '<rpm-build>'
+ /usr/bin/git add .
+ /usr/bin/git commit -q --allow-empty -a --author 'rpm-build <rpm-build>' -m 'jss-4.7.3 base'
+ exit 0
git操作目的是初始化一下 一会为下一次commit提供一个基础的 便于基于哪个生成patch
[root@x86builder jss]# cd BUILD/jss-4.7.3/
[root@x86builder jss-4.7.3]# ls
build build.sh cmake CMakeLists.txt docs gpl.txt jss.html jss.spec lgpl.txt lib MPL-1.1.txt org README.md samples tools
[root@x86builder jss-4.7.3]# git init
重新初始化已存在的 Git 仓库于 /root/work/build/centos/jss/BUILD/jss-4.7.3/.git/
[root@x86builder jss-4.7.3]# git add -f *
[root@x86builder jss-4.7.3]# git commit -a -m "init 001"
[master 3461ea5] init 001
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 build/.gitkeep
[root@x86builder jss-4.7.3]#
修改代码
[root@x86builder jss-4.7.3]# vim org/mozilla/jss/pkcs11/PKCS11Constants.java
原: public static final long CKK_SKIPJACK = 0x0000001BL;
修改后:public static final long CKK_SKIPJACK = 0x000001B9L;
再次提交 成成commmit
[root@x86builder jss-4.7.3]# git add -f *
[root@x86builder jss-4.7.3]# git commit -a -m "init 002"
[master efce2fb] init 002
1 file changed, 1 insertion(+), 1 deletion(-)
[root@x86builder jss-4.7.3]# git format-patch HEAD^ 或下面
[root@x86builder jss-4.7.3]# git format-patch 3461ea5b37c6a59ec2062e92842ffd483ee8dcfd
0001-init-002.patch
[root@x86builder jss-4.7.3]# cat 0001-init-002.patch
From efce2fb631a28bedf328c8246f902b557e31a610 Mon Sep 17 00:00:00 2001
From: rpm-build <rpm-build>
Date: Sat, 26 Mar 2022 14:48:49 +0800
Subject: [PATCH] init 002
---
org/mozilla/jss/pkcs11/PKCS11Constants.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/org/mozilla/jss/pkcs11/PKCS11Constants.java b/org/mozilla/jss/pkcs11/PKCS11Constants.java
index 7e3f3c0..f5d8956 100644
--- a/org/mozilla/jss/pkcs11/PKCS11Constants.java
+++ b/org/mozilla/jss/pkcs11/PKCS11Constants.java
@@ -585,7 +585,7 @@ public interface PKCS11Constants {
*
* Source file: /usr/include/nss3/pkcs11t.h
*/
- public static final long CKK_SKIPJACK = 0x0000001BL;
+ public static final long CKK_SKIPJACK = 0x000001B9L;
/**
* Content automatically generated; see NSS documentation for more information.
--
2.27.0
[root@x86builder jss-4.7.3]#
切回上一次,进行验证patch能否打上
[root@x86builder jss-4.7.3]# git checkout 3461ea5b37c6a59ec2062e92842ffd483ee8dcfd
[root@x86builder jss-4.7.3]# git apply --check 0001-init-002.patch
[root@x86builder jss-4.7.3]# 没有输出说明打上了
rpm:
[root@x86builder jss]# cat SPECS/jss.spec
Source: https://github.com/dogtagpki/%{name}/archive/v%{version}%{?_phase}/%{name}-%{version}%{?_phase}.tar.gz
#add patch 新加的
Patch1: 0001-init-002.patch
[root@x86builder jss]# ls SOURCES/
0001-init-002.patch jss-4.7.3.tar.gz
测试
[root@x86builder jss]# rpmbuild -bp SPECS/jss.spec --nodeps --define="_topdir $(pwd)"
git am
$ git apply --stat 0001-limit-log-function.patch # 查看patch的情况
$ git apply --check 0001-limit-log-function.patch # 检查patch是否能够打上,如果没有任何输出,则说明无冲突,可以打上
(注:git apply是另外一种打patch的命令,其与git am的区别是,git apply并不会将commit message等打上去,打完patch后需要重新git add和git commit,而git am会直接将patch的所有信息打上去,而且不用重新git add和git commit,author也是patch的author而不是打patch的人)
$ git am 0001-limit-log-function.patch # 将名字为0001-limit-log-function.patch的patch打上
$ git am --signoff 0001-limit-log-function.patch # 添加-s或者--signoff,还可以把自己的名字添加为signed off by信息,作用是注明打patch的人是谁,因为有时打patch的人并不是patch的作者
$ git am ~/patch-set/*.patch # 将路径~/patch-set/*.patch 按照先后顺序打上
$ git am --abort # 当git am失败时,用以将已经在am过程中打上的patch废弃掉(比如有三个patch,打到第三个patch时有冲突,那么这条命令会把打上的前两个patch丢弃掉,返回没有打patch的状态)
$ git am --resolved #当git am失败,解决完冲突后,这条命令会接着打patch
如果打Patch的过程中发生了冲突(conflicts),怎么办?
解决patch冲突的过程是:
如果不想打这一系列patch了,直接:git am --abort。
如果还想打, 有两种解决方案:
方案一:
(1) 根据git am失败的信息,找到发生冲突的具体patch文件,然后用命令git apply --reject <patch_name>,强行打这个patch,发生冲突的部分会保存为.rej文件(例如发生冲突的文件是a.txt,那么运行完这个命令后,发生conflict的部分会保存为a.txt.rej),未发生冲突的部分会成功打上patch
(2) 根据.rej文件,通过编辑该patch文件的方式解决冲突。
(3) 废弃上一条am命令已经打了的patch:git am --abort
(4) 重新打patch:git am ~/patch-set/*.patchpatch
方案二:
(1) 根据git am失败的信息,找到发生冲突的具体patch文件,然后用命令git apply --reject <patch_name>,强行打这个patch,发生冲突的部分会保存为.rej文件(例如发生冲突的文件是a.txt,那么运行完这个命令后,发生conflict的部分会保存为a.txt.rej),未发生冲突的部分会成功打上patch
(2) 根据.rej文件,通过编辑发生冲突的code文件的方式解决冲突。
(3) 将该patch涉及到的所有文件(不仅仅是发生冲突的文件)通过命令git add <file_name>添加到工作区中
(4) 告诉git冲突已经解决,继续打patch: git am --resolved (git am --resolved 和 git am --continue是一样的)
分析:方案一和方案二主要区别是解决冲突的方法不一样。方案一是通过编辑patch文件的方式解决冲突,方案二是通过编辑冲突code文件的方式解决冲突。这两种方案区别比较大:经过实验,核心区别在于,方案一在修改patch时,如果修改的地方比较多,patch可能就打不上了,因为patch文件里对改动的行和列,以及修改了几个字符有精确的描述,很可能你改了想改的代码,却不符合描述了,就无法apply上Patch。方案二无法验证冲突有没有切实的解决。即使你在方案二的第二步乱改一通,也能“打完”发生冲突的patch(并没有检测修改后的code文件跟patch期望的是否相同)。因此,如果采用方案二,那么再解决code文件冲突后,需要人工去确认修改的正确性。
+换成plus
[root@git perl-Text-Tabs+Wrap.git]# git clone --mirror https://git.centos.org/rpms/perl-Text-Tabs+Wrap.git
[root@git perl-Text-Tabs+Wrap.git]# git push --mirror https://git.cclinux.com.cn/upstream/rpms/perl-Text-TabsplusWrap.git
srpmproc 源码支持+换成plus