很失败,工作三年多了,才会用git am相关指令,而且一直自诩从事linux驱动、内核开发的老手,哎!
本文作为自己对自己这几年来混吃等死的批判。
此处说明的是,在看完该文后,回头看这些内容:
补丁可能是自己弄的或者是从社区获取的,不管是哪种,都需要添加上自己的信息,
自己做的话,在git commit的时候可以:
git commit -s #就可以将自己相关信息 signed off上去。
从社区或者别处获取的,在打上去的时候,可以
git am -s #通过这种方式,同样就将自己信息signed off上去了。
git format-patch制作patch常用的几种格式
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) 此处表示的是最新的commit到自己前面一个commit的所有patch git format-patch --root <r1> #生成从根到r1提交的所有patch
需要说明的是,git format-patch head^指令虽然正宗,但是输入指令个人还是觉得比较麻烦的,你可以直接采用如下指令生成patch:
git format-patch -1 #生成当前commit的patch
git format-patch -8 # 生成最新8个commit的patch,注意顺序,最新的commit的patch编号一定是0008-xxxx
git format-patch cover-letter制作补丁说明
补丁制作完成后,需要你的上级或者同事审查,这种情况下,你该怎么制作补丁呢???,你可以通过git format-patch --cover-letter -8指令,制作8个补丁,并包含一个0000开头的patch
介绍该8个补丁的改动情况。
打开该文件,你可以看到对这8个patch的总体介绍
From fd6988496e79a6a4bdb514a4655d2920209eb85d Mon Sep 17 00:00:00 2001
From: hanle <hanle@localhost.(none)>
Date: Sat, 4 Jan 2020 23:40:27 +0800
Subject: [PATCH 0/8] *** SUBJECT HERE *** # 在此处总体介绍下你的补丁。
*** BLURB HERE *** # 在此处添加你个人对着系列补丁的一个介绍,不用介绍的太详细
Amir Goldstein (1):
locks: print unsigned ino in /proc/locks
David Abdurachmanov (1):
riscv: reject invalid syscalls below -1
Florian Fainelli (3):
ata: ahci_brcm: Fix AHCI resources management
ata: ahci_brcm: BCM7425 AHCI requires AHCI_HFLAG_DELAY_ENGINE
ata: ahci_brcm: Add missing clock management during recovery
Linus Torvalds (1):
Linux 5.5-rc4
Luc Van Oostenryck (1):
riscv: fix compile failure with EXPORT_SYMBOL() & !MMU
Olof Johansson (1):
riscv: export flush_icache_all to modules
--
2.24.1
git am打补丁的技巧
git打补丁的方式包括两种:
git am 和 git apply,两者之间有什么区别呢?两者之间的区别在于commit信息,前者只要打补丁成功,必定包括自带的commit的信息,当然你可以-s 加上你本人的singed off信息。
而后者相当于修改了文件,并且执行了git add -u *之类的指令,但是不会生成commit信息,这个信息需要你本人自己添加,也就是说,该补丁最后生成的commit信息是你自己需要
构造的。
下面具体介绍这两种指令
git apply:
git apply xxx.patch # 打上patch
git apply --stat xxx.patch # 查看patch的情况 git apply --check xxx.patch # 检查patch是否能够打上,如果没有任何输出,则说明无冲突,可以打上
git am:
git am xxx.patch # 将名字为0001-limit-log-function.patch的patch打上 git am --signoff xxx.patch # 添加-s或者--signoff,还可以把自己的名字添加为signed off by信息,作用是注明打patch的人是谁 git am *.patch # 批量打上patch,并且安装000x的序号先后打上patch,此处需要说明的每一个patch之间最好没有依赖关系,如果有依赖关系,可以修改000x序号,
# 把需要被依赖的patch先打上。
git am --abort # git patch过程中如果遇到的冲突怎么办,可以通过加上--abort指令撤回打的patch。
以上两种打patch的方式,可以根据需要操作,下面以git am为例,打补丁的过程中出现冲突该怎么处理。
git am打补丁解决冲突的方法
在打补丁的过程中,遇到冲突是不可避免的,尤其是patch来源于不一致的内核版本。
如果出现冲突,相放弃打patch,直接git am --abort即可,当然一遇到冲突就放弃打patch,实在有点说不过去。
如果在执行git am xxx.patch的时候,出现冲突,会自动在冲突文件所在的目录生成一个xxx.rej文件,里面介绍了冲突具体位置,需要按照xxx.rej的方式手动修改冲突内容。
对于冲突较多的情况,这种手工的方式确实费时费力,但是有些情况下确实没更好的办法,若想打patch成功的话,只能这么做了。
- 1、git am冲突后,可以先执行git apply --reject将不冲突的代码打入文件中。
- 2、按照xxx.rej的指示,手动修改冲突文件内容,修改完成后,删除xxx.rej文件。
- 3、执行git add .指令,将修改后的文件add进去。
- 4、执行git am --resolved即可将有冲突的补丁打成功,若此过程还是失败,再次执行2~4步骤即可。