Git-中文参考-七-

Git 中文参考(七)

原文:Git Reference

协议:CC BY-NC-SA 4.0

git-daemon

原文: git-scm.com/docs/git-daemon

名称

git-daemon - Git 存储库的一个非常简单的服务器

概要

git daemon [--verbose] [--syslog] [--export-all]
	     [--timeout=<n>] [--init-timeout=<n>] [--max-connections=<n>]
	     [--strict-paths] [--base-path=<path>] [--base-path-relaxed]
	     [--user-path | --user-path=<path>]
	     [--interpolated-path=<pathtemplate>]
	     [--reuseaddr] [--detach] [--pid-file=<file>]
	     [--enable=<service>] [--disable=<service>]
	     [--allow-override=<service>] [--forbid-override=<service>]
	     [--access-hook=<path>] [--[no-]informative-errors]
	     [--inetd |
	      [--listen=<host_or_ipaddr>] [--port=<n>]
	      [--user=<user> [--group=<group>]]]
	     [--log-destination=(stderr|syslog|none)]
	     [<directory>…​]

描述

一个非常简单的 TCP Git 守护程序,它通常侦听端口“DEFAULT_GIT_PORT”,即 9418.它等待连接请求服务,并且如果启用该服务将服务该服务。

它验证该目录是否具有魔术文件“git-daemon-export-ok”,并且它将拒绝导出任何未明确标记为以这种方式导出的 Git 目录(除非指定了--export-all参数)。如果您将某些目录路径作为 _git 守护程序 _ 参数传递,则可以进一步将要约限制为包含这些路径的白名单。

默认情况下,仅启用upload-pack服务,该服务为 git fetch-packgit ls-remote 客户端提供服务,这些客户端是从 git fetch 调用的, git pullgit clone

这非常适合只读更新,即从 Git 存储库中提取。

还存在upload-archive以服务 _git 存档 _。

OPTIONS

 --strict-paths 

完全匹配路径(即当真实路径是“/foo/repo.git”或“/foo/repo/.git”时不允许“/ foo / repo”)并且不做用户相对路径。启用此选项且未指定白名单时, _git 守护程序 _ 将拒绝启动。

 --base-path=<path> 

将所有路径请求重新映射为相对于给定路径。这有点像“Git root” - 如果你在 example.com 上用 --base-path = / srv / git 运行 _git 守护进程 _,那么如果你以后尝试拉 git://example.com/hello.git , _git 守护程序 _ 会将路径解释为 /srv/git/hello.git

 --base-path-relaxed 

如果启用了--base-path 并且 repo lookup 失败,则使用此选项 _git 守护程序 _ 将尝试在不添加基本路径前缀的情况下进行查找。这对于切换到--base-path 用法很有用,同时仍允许旧路径。

 --interpolated-path=<pathtemplate> 

为了支持虚拟主机,可以使用内插路径模板来动态构建备用路径。模板支持客户端提供的目标主机名%H,但转换为全部小写,%CH 为规范主机名,%IP 为服务器 IP 地址,%P 为端口号,%D 为绝对路径命名的存储库。插值后,路径将根据目录白名单进行验证。

 --export-all 

允许从所有看起来像 Git 存储库的目录(具有 _ 对象 _ 和 refs 子目录)中拉出,即使它们没有 git-daemon-export-ok ]文件。

 --inetd 

让服务器作为 inetd 服务运行。意味着--sloglog(可以用--log-destination=覆盖)。与--detach, - port, - liste, - user 和--group 选项不兼容。

 --listen=<host_or_ipaddr> 

收听特定的 IP 地址或主机名。如果支持,IP 地址可以是 IPv4 地址或 IPv6 地址。如果不支持 IPv6,则也不支持--listen = hostname,并且必须为--listen 提供 IPv4 地址。可以不止一次。与--inetd选项不兼容。

 --port=<n> 

听另一个端口。与--inetd选项不兼容。

 --init-timeout=<n> 

建立连接的时刻与收到客户端请求之间的超时(以秒为单位)(通常是一个相当低的值,因为它应该基本上是立即的)。

 --timeout=<n> 

特定客户端子请求的超时(以秒为单位)。这包括服务器处理子请求所花费的时间以及等待下一个客户端请求所花费的时间。

 --max-connections=<n> 

最大并发客户端数,默认为 32.将其设置为零,无限制。

 --syslog 

--log-destination=syslog的缩写。

 --log-destination=<destination> 

将日志消息发送到指定目标。请注意,此选项并不意味着--verbose,因此默认情况下仅记录错误条件。 < destination>必须是以下之一:

 stderr 

写入标准错误。请注意,如果指定了--detach,则进程将脱离实际标准错误,使此目标有效地等效于none

 syslog 

使用git-daemon标识符写入 syslog。

 none 

禁用所有日志记录

如果指定了--inetd--detach,则默认目标为syslog,否则为stderr

 --user-path 
 --user-path=<path> 

允许〜用户表示法用于请求。当没有参数指定时,对 git:// host / ~alice / foo 的请求被视为访问用户alice主目录中的 foo 存储库的请求。如果指定了--user-path=path,则将相同的请求作为访问用户alice的主目录中的path/foo存储库的请求。

 --verbose 

记录有关传入连接和请求文件的详细信息。

 --reuseaddr 

绑定侦听套接字时使用 SO_REUSEADDR。这允许服务器重新启动而无需等待旧连接超时。

 --detach 

脱离外壳。意味着--sloglog。

 --pid-file=<file> 

将进程 ID 保存在 _ 文件 _ 中。守护程序在--inetd下运行时忽略。

 --user=<user> 
 --group=<group> 

在进入服务循环之前更改守护进程的 uid 和 gid。如果仅在没有--group的情况下给出--user,则使用用户的主要组 ID。选项的值赋予getpwnam(3)getgrnam(3),不支持数字 ID。

--inetd一起使用时,给出这些选项是错误的;如果需要,在产生 _git 守护程序 _ 之前使用 inet 守护程序的功能来实现相同的功能。

与许多切换用户 ID 的程序一样,守护程序在运行 git 程序时不会重置诸如$HOME之类的环境变量,例如upload-packreceive-pack。使用此选项时,您可能还需要在启动守护程序之前将HOME设置并导出到&lt;user&gt;的主目录,并确保&lt;user&gt;可读取该目录中的任何 Git 配置文件。

 --enable=<service> 
 --disable=<service> 

默认情况下在站点范围内启用/禁用服务。请注意,如果某个服务器标记为可覆盖,并且存储库通过配置项启用该服务,则仍可以为每个存储库启用站点范围内禁用的服务。

 --allow-override=<service> 
 --forbid-override=<service> 

允许/禁止使用每个存储库配置覆盖站点范围的默认值。默认情况下,可以覆盖所有服务。

 --[no-]informative-errors 

当打开信息性错误时,git-daemon 将向客户端报告更详细的错误,将“no such repository”等条件与“未导出的存储库”区分开来。这对客户来说更方便,但可能会泄漏有关未导出存储库存在的信息。如果未启用信息性错误,则所有错误都会向客户端报告“拒绝访问”。默认值为--no-informative-errors。

 --access-hook=<path> 

每次客户端连接时,首先运行由< path>指定的外部命令。具有服务名称(例如“upload-pack”),存储库的路径,主机名(%H),规范主机名(%CH),IP 地址(%IP)和 TCP 端口(%P)作为其命令行参数。外部命令可以通过退出非零状态(或通过以零状态退出来允许它)来决定拒绝服务。在做出此决定时,它还可以查看$ REMOTE_ADDR 和$REMOTE_PORT环境变量以了解请求者。

外部命令可以选择将单行写入其标准输出,以便在拒绝服务时将其作为错误消息发送给请求者。

 <directory> 

要添加到允许目录的白名单的目录。除非指定了--strict-paths,否则这还将包括每个命名目录的子目录。

服务

可以使用此命令的命令行选项全局启用/禁用这些服务。如果需要更细粒度的控制(例如,允许 git archive 仅在守护程序所服务的几个选定的存储库中运行),则每个存储库配置文件可用于启用或禁用它们。

 upload-pack 

这服务于 git fetch-packgit ls-remote 客户端。它默认启用,但存储库可以通过将daemon.uploadpack配置项设置为false来禁用它。

 upload-archive 

这服务 git archive --remote 。默认情况下禁用它,但存储库可以通过将daemon.uploadarch配置项设置为true来启用它。

 receive-pack 

这为 git send-pack 客户端提供服务,允许匿名推送。它默认是禁用的,因为协议中有 _ 没有 _ 身份验证(换句话说,任何人都可以将任何内容推送到存储库中,包括删除引用)。这仅适用于每个人都很友好的封闭式 LAN 环境。可以通过将daemon.receivepack配置项设置为true来启用此服务。

例子

 We assume the following in /etc/services 
$ grep 9418 /etc/services
git		9418/tcp		# Git Version Control System
 git daemon as inetd server 

要将 _git 守护程序 _ 设置为处理列入白名单的目录集/ pub / foo 和/ pub / bar 下的任何存储库的 ine​​td 服务,请将以下条目放入/ etc / inetd all in one 线:

	git stream tcp nowait nobody  /usr/bin/git
		git daemon --inetd --verbose --export-all
		/pub/foo /pub/bar
 git daemon as inetd server for virtual hosts 

要将 _git 守护程序 _ 设置为处理不同虚拟主机www.example.comwww.example.org的存储库的 ine​​td 服务,请在/etc/inetd中将以下条目全部放在一行:

	git stream tcp nowait nobody /usr/bin/git
		git daemon --inetd --verbose --export-all
		--interpolated-path=/pub/%H%D
		/pub/www.example.org/software
		/pub/www.example.com/software
		/software

在此示例中,根级目录/pub将包含支持的每个虚拟主机名的子目录。此外,两个主机都将存储库简单地称为git://www.example.com/software/repo.git。对于 1.4.0 之前的客户端,也可以将/software中的符号链接添加到相应的默认存储库中。

 git daemon as regular daemon for virtual hosts 

要将 _git 守护程序 _ 设置为常规的非 inetd 服务,根据其 IP 地址处理多个虚拟主机的存储库,请启动守护程序,如下所示:

	git daemon --verbose --export-all
		--interpolated-path=/pub/%IP/%D
		/pub/192.168.1.200/software
		/pub/10.10.220.23/software

在此示例中,根级目录/pub将包含支持的每个虚拟主机 IP 地址的子目录。但是,主机名仍然可以访问存储库,假设它们对应于这些 IP 地址。

 selectively enable/disable services per repository 

要启用 git archive --remote 并禁用存储库中的 git fetch ,请在存储库的配置文件中保存以下内容(即文件 config next 到HEADrefs 和 _ 对象 _)。

	[daemon]
		uploadpack = false
		uploadarch = true

环境

如果 IP 地址可用, _git 守护程序 _ 会将 REMOTE_ADDR 设置为与其连接的客户端的 IP 地址。 REMOTE_ADDR 将在执行服务时调用的挂钩环境中可用。

GIT

部分 git [1] 套件

git-update-server-info

原文: git-scm.com/docs/git-update-server-info

名称

git-update-server-info - 更新辅助信息文件以帮助虚拟服务器

概要

git update-server-info [--force]

描述

没有动态包生成的哑服务器必须在$ GIT_DIR / info 和$ GIT_OBJECT_DIRECTORY / info 目录中包含一些辅助信息文件,以帮助客户端发现服务器具有哪些引用和包。此命令生成此类辅助文件。

OPTIONS

 -f 
 --force 

从头开始更新信息文件。

OUTPUT

目前,该命令会更新以下文件。请参阅 gitrepository-layout [5] ,了解它们的用途:

  • 对象/信息/包

  • 信息/裁判

GIT

部分 git [1] 套件

git-cat-file

原文: git-scm.com/docs/git-cat-file

名称

git-cat-file - 提供存储库对象的内容或类型和大小信息

概要

git cat-file (-t [--allow-unknown-type]| -s [--allow-unknown-type]| -e | -p | <type> | --textconv | --filters ) [--path=<path>] <object>
git cat-file (--batch | --batch-check) [ --textconv | --filters ] [--follow-symlinks]

描述

在第一种形式中,该命令提供存储库中对象的内容或类型。除非使用-t-p查找对象类型,或者使用-s查找对象大小,或使用--textconv--filters(暗示类型为“blob”),否则类型是必需的。

在第二种形式中,stdin 上提供了一个对象列表(由换行符分隔),每个对象的 SHA-1,类型和大小都打印在 stdout 上。可以使用可选的&lt;format&gt;参数覆盖输出格式。如果指定了--textconv--filters,则输入应该列出对象名称,后跟路径名称,由单个空格分隔,以便可以确定相应的驱动程序。

OPTIONS

 <object> 

要显示的对象的名称。有关拼写对象名称的更完整列表,请参阅 gitrevisions [7] 中的“指定修订”部分。

 -t 

而不是内容,显示由< object>标识的对象类型。

 -s 

而不是内容,显示由< object>标识的对象大小。

 -e 

如果< object>,则退出为零状态存在并且是一个有效的对象。如果< object>是非格式的无效格式退出非零,并在 stderr 上发出错误。

 -p 

漂亮打印< object>的内容根据其类型。

 <type> 

通常,这与< object>的实际类型匹配。但是要求一种可以从给定的< object>中解除引用的类型。也是允许的。一个例子是要求一个带有< object>的“树”。是包含它的提交对象,或者要求< object>的“blob”是一个指向它的标记对象。

 --textconv 

显示由 textconv 过滤器转换的内容。在这种情况下,< object>必须采用< tree-ish>形式:< path>或:< path>为了将过滤器应用于< path>中索引中记录的内容。

 --filters 

显示由当前工作树中为给定< path>配置的过滤器转换的内容。 (即涂抹过滤器,行尾转换等)。在这种情况下,< object>必须是< tree-ish>:< path>或:< path>的形式。

 --path=<path> 

与--textconv 或--filters 一起使用时,允许单独指定对象名称和路径,例如当很难弄清楚 blob 来自的修订版。

 --batch 
 --batch=<format> 

打印 stdin 上提供的每个对象的对象信息和内容。除了--textconv--filters之外,不能与任何其他选项或参数组合使用,在这种情况下,输入行也需要指定路径,用空格分隔。有关详细信息,请参阅下面的BATCH OUTPUT部分。

 --batch-check 
 --batch-check=<format> 

打印 stdin 上提供的每个对象的对象信息。除了--textconv--filters之外,不能与任何其他选项或参数组合使用,在这种情况下,输入行也需要指定路径,用空格分隔。有关详细信息,请参阅下面的BATCH OUTPUT部分。

 --batch-all-objects 

不是在 stdin 上读取对象列表,而是对存储库中的所有对象和任何备用对象存储(不仅仅是可访问的对象)执行请求的批处理操作。需要指定--batch--batch-check。请注意,按顺序访问对象按其哈希值排序。

 --buffer 

通常在输出每个对象后刷新批输出,以便进程可以从cat-file以交互方式读写。使用此选项,输出使用正常的 stdio 缓冲;在大量对象上调用--batch-check时效率更高。

 --unordered 

使用--batch-all-objects时,按顺序访问对象,这可能比散列顺序更有效地访问对象内容。订单的确切细节未指定,但如果您不需要特定订单,这通常会导致更快的输出,尤其是--batch。请注意,cat-file仍将仅显示每个对象一次,即使它在存储库中多次存储也是如此。

 --allow-unknown-type 

允许-s 或-t 查询未知类型的已损坏/损坏对象。

 --follow-symlinks 

使用--batch 或--batch-check 时,在请求具有树形式为 tree-ish:path-in-tree 的扩展 SHA-1 表达式的对象时,请遵循存储库中的符号链接。不提供有关链接本身的输出,而是提供有关链接对象的输出。如果符号链接指向树之外(例如指向/ foo 的链接或指向../foo 的根级链接),则将打印链接在树之外的部分。

当指定索引中的对象(例如:link而不是HEAD:link)而不是树中的对象时,此选项(当前)不能正常工作。

除非使用--batch--batch-check,否则不能(当前)使用此选项。

例如,考虑一个包含以下内容的 git 存储库:

f: a file containing "hello\n"
link: a symlink to f
dir/link: a symlink to ../f
plink: a symlink to ../f
alink: a symlink to /etc/passwd

对于常规文件f,将打印echo HEAD:f | git cat-file --batch

ce013625030ba8dba906f756967f9e9ca394464a blob 6

并且echo HEAD:link | git cat-file --batch --follow-symlinks将打印与HEAD:dir/link相同的内容,因为它们都指向HEAD:f

没有--follow-symlinks,这些将打印有关符号链接本身的数据。在HEAD:link的情况下,你会看到

4d1ae35ba2c8ec712fa2a379db44ad639ca277bd blob 1

plinkalink都指向树外,因此它们将分别打印:

symlink 4
../f
symlink 11
/etc/passwd

OUTPUT

如果指定了-t,则其中一个< type>。

如果指定了-s,则< object>的大小。以字节为单位

如果指定了-e,则不输出,除非< object>是畸形的

如果指定了-p,则< object>的内容很漂亮。

如果< type>指定了< object>的原始(虽然未压缩)内容。将被退回。

批量输出

如果给出--batch--batch-checkcat-file将从标准输入读取对象,每行一个,并打印有关它们的信息。默认情况下,整行被视为一个对象,就像它被送到 git-rev-parse [1] 一样。

您可以使用自定义&lt;format&gt;指定为每个对象显示的信息。 &lt;format&gt;按字面复制到每个对象的 stdout,展开%(atom)形式的占位符,后跟换行符。可用的原子是:

 objectname 

对象的 40 十六进制对象名称。

 objecttype 

对象的类型(与cat-file -t报告相同)。

 objectsize 

对象的大小(以字节为单位)(与cat-file -s报告相同)。

 objectsize:disk 

对象占用磁盘的大小(以字节为单位)。请参阅下面CAVEATS部分中有关磁盘大小的说明。

 deltabase 

如果对象存储为磁盘上的增量,则会扩展为增量基础对象的 40-hex sha1。否则,展开为空 sha1(40 个零)。见下面的CAVEATS

 rest 

如果在输出字符串中使用此原子,则输入行将在第一个空白边界处拆分。在该空格之前的所有字符都被认为是对象名称;在第一次运行空白之后的字符(即,行的“其余”)被输出以代替%(rest)原子。

如果未指定格式,则默认格式为%(objectname) %(objecttype) %(objectsize)

如果指定了--batch,则对象信息后跟对象内容(由%(objectsize)字节组成),后跟换行符。

例如,没有自定义格式的--batch会产生:

<sha1> SP <type> SP <size> LF
<contents> LF

--batch-check='%(objectname) %(objecttype)'会产生:

<sha1> SP <type> LF

如果在 stdin 上指定了无法解析为存储库中对象的名称,则cat-file将忽略任何自定义格式并打印:

<object> SP missing LF

如果指定的名称可能引用多个对象(模糊的短 sha),则cat-file将忽略任何自定义格式并打印:

<object> SP ambiguous LF

如果使用了--follow-symlinks,并且存储库中的符号链接指向存储库外部,则cat-file将忽略任何自定义格式并打印:

symlink SP <size> LF
<symlink> LF

符号链接将是绝对的(以/开头)或相对于树根。例如,如果 dir / link 指向../../foo,那么< symlink>将是../foo。 <大小>符号链接的大小(以字节为单位)。

如果使用--follow-symlinks,将显示以下错误消息:

<object> SP missing LF

在请求的初始符号链接不存在时打印。

dangling SP <size> LF
<object> LF

在初始符号链接存在时打印,但它(transitive-of)指向的符号链接不存在。

loop SP <size> LF
<object> LF

打印用于符号链接循环(或任何需要解析超过 40 个链接分辨率的符号链接)。

notdir SP <size> LF
<object> LF

在符号链接解析期间,当文件用作目录名时,将打印。

CAVEATS

请注意,磁盘上对象的大小是准确报告的,但应该注意得出哪些引用或对象负责磁盘使用的结论。打包的非 delta 对象的大小可能远大于对其增量的对象的大小,但是选择哪个对象是基础并且 delta 是任意的并且在重新打包期间可能会发生变化。

还要注意,对象的多个副本可能存在于对象数据库中;在这种情况下,未定义将报告哪个副本的大小或增量基数。

GIT

部分 git [1] 套件

git-check-ignore

原文: git-scm.com/docs/git-check-ignore

名称

git-check-ignore - 调试 gitignore / exclude 文件

概要

git check-ignore [<options>] <pathname>…​
git check-ignore [<options>] --stdin

描述

对于通过命令行或通过--stdin从文件给出的每个路径名,检查文件是否被.gitignore(或排除机制的其他输入文件)排除,并输出路径(如果它被排除)。

默认情况下,跟踪文件根本不显示,因为它们不受排除规则的约束;但请参阅'--no-index'。

OPTIONS

 -q, --quiet 

不要输出任何内容,只需设置退出状态即可。这仅对单个路径名有效。

 -v, --verbose 

还输出有关每个给定路径名的匹配模式(如果有)的详细信息。有关排除源内和排除源之间的优先级规则,请参阅 gitignore [5]

 --stdin 

从标准输入读取路径名,每行一个,而不是命令行。

 -z 

输出格式被修改为可机器解析(见下文)。如果还给出--stdin,则输入路径用 NUL 字符而不是换行符分隔。

 -n, --non-matching 

显示与任何模式都不匹配的给定路径。这仅在启用--verbose时才有意义,否则将无法区分匹配模式的路径和不匹配模式的路径。

 --no-index 

在进行检查时不要查看索引。这可以用于调试由例如跟踪路径的原因。 git add .并且未被用户预期的规则忽略,或者在开发包含否定的模式以匹配先前使用git add -f添加的路径时。

OUTPUT

默认情况下,将输出与忽略模式匹配的任何给定路径名,每行一个。如果没有模式匹配给定路径,则不会为该路径输出任何内容;这意味着路径不会被忽略。

如果指定了--verbose,则输出是以下形式的一系列行:

<信源> <结肠癌和 GT; < LINENUM> <结肠癌和 GT; <模式> < HT> <路径名>

<路径名>是要查询的文件的路径,< pattern>是匹配模式,< source>是模式的源文件,< linenum>是该源中模式的行号。如果模式包含!前缀或/后缀,则它将保留在输出中。 <信源>在引用core.excludesFile配置的文件时,或者在引用.git/info/exclude或每个目录的排除文件时相对于存储库根目录时,它将是绝对路径。

如果指定了-z,则输出中的路径名由空字符分隔;如果还指定了--verbose,则还使用空字符代替冒号和硬标签:

<信源> < NULL> < LINENUM> < NULL> <模式> < NULL> <路径名> < NULL>

如果指定了-n--non-matching,则还将输出不匹配的路径名,在这种情况下,每个输出记录中的所有字段除了< pathname>将是空的。这在非交互式运行时非常有用,因此可以将文件递增地流式传输到长时间运行的检查忽略过程的 STDIN,并且对于每个文件,STDOUT 将指示该文件是否与模式匹配。 (如果没有这个选项,就不可能判断给定文件的输出是否缺少意味着它是否与任何模式不匹配,或者输出是否尚未生成。)

缓冲发生在 git [1]GIT_FLUSH选项中。调用者负责避免因输入缓冲区过满或从空输出缓冲区读取而导致的死锁。

退出状态

 0 

忽略一个或多个提供的路径。

 1 

没有提供的路径被忽略。

 128 

遇到致命错误。

也可以看看

gitignore [5] git-config [1] git-ls-files [1]

GIT

部分 git [1] 套件

git-checkout-index

原文: git-scm.com/docs/git-checkout-index

名称

git-checkout-index - 将文件从索引复制到工作树

概要

git checkout-index [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
		   [--stage=<number>|all]
		   [--temp]
		   [-z] [--stdin]
		   [--] [<file>…​]

描述

将索引中列出的所有文件复制到工作目录(不覆盖现有文件)。

OPTIONS

 -u 
 --index 

更新索引文件中已签出条目的统计信息。

 -q 
 --quiet 

如果文件存在或不在索引中,请保持安静

 -f 
 --force 

强制覆盖现有文件

 -a 
 --all 

检出索引中的所有文件。不能与显式文件名一起使用。

 -n 
 --no-create 

不要签出新文件,只刷新已经签出的文件。

 --prefix=<string> 

创建文件时,请添加< string> (通常是包含尾随的目录/)

 --stage=<number>|all 

不要检出未合并的条目,而是从命名阶段复制出文件。 <数>必须介于 1 和 3 之间。注意: - stage = all 自动隐含--temp。

 --temp 

而不是将文件复制到工作目录,而是将内容写入临时文件。临时名称关联将写入 stdout。

 --stdin 

而不是从命令行获取路径列表,从标准输入中读取路径列表。默认情况下,路径由 LF(即每行一个路径)分隔。

 -z 

仅对--stdin有意义;路径用 NUL 字符而不是 LF 分隔。

 -- 

不要将任何更多的参数解释为选项。

标志的顺序过去很重要,但现在不再重要。

刚做git checkout-index什么也没做。你可能意味着git checkout-index -a。如果你想强制它,你想要git checkout-index -f -a

直觉不是这里的目标。重复性是。 “没有参数意味着没有工作”行为的原因是你应该能够做到的脚本:

$ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --

这将强制所有现有的*.h文件替换为其缓存副本。如果一个空命令行暗示“全部”,那么这将强制刷新索引中的所有内容,这不是重点。但是因为 git checkout-index 接受--stdin 它会更快使用:

$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin

当你知道其余的是文件名时,--是个好主意。它可以防止文件名出现问题,例如-a。在脚本中使用--可能是一个很好的策略。

使用--temp 或--stage = all

当使用--temp(或--stage=all暗示)_ 时,git checkout-index_ 将为每个要检出的索引条目创建一个临时文件。索引不会使用统计信息进行更新。如果调用者需要所有未合并条目的所有阶段,以便外部合并工具可以处理未合并文件,则这些选项非常有用。

列表将写入 stdout,提供临时文件名与跟踪路径名的关联。列表格式有两种变体:

  1. tempname TAB 路径 RS

    第一种格式是省略--stage或不是--stage=all时使用的格式。字段 tempname 是保存文件内容的临时文件名,path 是索引中的跟踪路径名。仅输出所请求的条目。

  2. stage1temp SP stage2temp SP stage3tmp TAB 路径 RS

    第二种格式是--stage=all时使用的格式。如果索引中存在阶段条目,则三阶段临时字段(stage1temp,stage2temp,stage3temp)列出临时文件的名称;如果没有阶段条目,则列出.。将始终从输出中省略仅具有阶段 0 条目的路径。

在两种格式中,RS(记录分隔符)默认为换行符,但如果在命令行上传递-z,则为空字节。临时文件名始终是安全字符串;它们永远不会包含目录分隔符或空格字符。 path 字段始终相对于当前目录,临时文件名始终相对于顶级目录。

如果要复制到临时文件的对象是符号链接,则链接的内容将写入普通文件。最终用户或瓷器可以使用这些信息。

例子

 To update and refresh only the files already checked out 
$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
 Using git checkout-index to "export an entire tree" 

前缀能力基本上使得 git checkout-index 用作“导出为树”功能变得微不足道。只需将所需的树读入索引,然后执行:

$ git checkout-index --prefix=git-export-dir/ -a

git checkout-index将索引“导出”到指定目录中。

最后的“/”很重要。导出的名称实际上只是以指定的字符串为前缀。将此与下面的示例进行对比。

 Export files with a prefix 
$ git checkout-index --prefix=.merged- Makefile

这将检出当前缓存的Makefile副本到文件.merged-Makefile中。

GIT

部分 git [1] 套件

git-commit-tree

原文: git-scm.com/docs/git-commit-tree

名称

git-commit-tree - 创建一个新的提交对象

概要

git commit-tree <tree> [(-p <parent>)…​]
git commit-tree [(-p <parent>)…​] [-S[<keyid>]] [(-m <message>)…​]
		  [(-F <file>)…​] <tree>

描述

这通常不是最终用户想要直接运行的。参见 git-commit [1]

基于提供的树对象创建新的提交对象,并在 stdout 上发出新的提交对象 ID。除非给出-m-F选项,否则将从标准输入读取日志消息。

提交对象可以包含任意数量的父项。只有一个父,它是一个普通的提交。拥有多个父级会使提交在多行历史记录之间合并。初始(root)提交没有父母。

虽然树表示工作目录的特定目录状态,但提交在“时间”中表示该状态,并说明如何到达那里。

通常一个提交会识别一个新的“HEAD”状态,而 Git 并不关心你在哪里保存关于该状态的注释,实际上我们倾向于只将结果写入.git/HEAD所指向的文件,所以我们总能看到最后承诺的状态是什么。

OPTIONS

 <tree> 

现有的树对象

 -p <parent> 

每个-p表示父提交对象的 id。

 -m <message> 

提交日志消息中的段落。这可以被给予不止一次并且每个<消息>成为自己的段落。

 -F <file> 

从给定文件中读取提交日志消息。使用-从标准输入读取。

 -S[<keyid>] 
 --gpg-sign[=<keyid>] 

GPG 签名提交。 keyid参数是可选的,默认为提交者标识;如果指定,它必须粘在没有空格的选项上。

 --no-gpg-sign 

不要 GPG 签名提交,以反击命令行先前给出的--gpg-sign选项。

提交信息

提交封装:

  • 所有父对象 id

  • 作者姓名,电子邮件和日期

  • 提交者姓名和电子邮件以及提交时间。

在命令行上提供父对象 ID 时,作者和提交者信息取自以下环境变量,如果设置:

GIT_AUTHOR_NAME
GIT_AUTHOR_EMAIL
GIT_AUTHOR_DATE
GIT_COMMITTER_NAME
GIT_COMMITTER_EMAIL
GIT_COMMITTER_DATE

(nb“<”,“>”和“\ n”s 被剥离)

如果未设置(某些)这些环境变量,则从配置项 user.name 和 user.email 获取信息,如果不存在,则获取环境变量 EMAIL,或者,如果未设置,则系统用户用于发送邮件的名称和主机名(取自/etc/mailname并在该文件不存在时回退到完全限定的主机名)。

从 stdin 读取提交注释。如果未通过“<”提供更改日志条目重定向, git commit-tree 将等待一个输入并终止于^ D.

日期格式

GIT_AUTHOR_DATEGIT_COMMITTER_DATE环境变量支持以下日期格式:

 Git internal format 

它是&lt;unix timestamp&gt; &lt;time zone offset&gt;,其中&lt;unix timestamp&gt;是自 UNIX 纪元以来的秒数。 &lt;time zone offset&gt;是 UTC 的正偏移或负偏移。例如,CET(比 UTC 早 1 小时)是+0100

 RFC 2822 

RFC 2822 描述的标准电子邮件格式,例如Thu, 07 Apr 2005 22:13:13 +0200

 ISO 8601 

ISO 8601 标准规定的时间和日期,例如2005-04-07T22:13:13。解析器也接受空格而不是T字符。

| 注意 | 此外,日期部分以下列格式接受:YYYY.MM.DDMM/DD/YYYYDD.MM.YYYY。 |

讨论

Git 在某种程度上是字符编码不可知的。

  • blob 对象的内容是未解释的字节序列。核心级别没有编码转换。

  • 路径名以 UTF-8 规范化形式 C 编码。这适用于树对象,索引文件,ref 名称,以及命令行参数,环境变量和配置文件中的路径名(.git/config(参见 git) -config [1] ), gitignore [5]gitattributes [5]gitmodules [5] )。

    请注意,核心级别的 Git 仅将路径名称视为非 NUL 字节序列,没有路径名称编码转换(Mac 和 Windows 除外)。因此,即使在使用传统扩展 ASCII 编码的平台和文件系统上,使用非 ASCII 路径名也会起作用。但是,在此类系统上创建的存储库将无法在基于 UTF-8 的系统(例如 Linux,Mac,Windows)上正常工作,反之亦然。此外,许多基于 Git 的工具只是假设路径名为 UTF-8,并且无法正确显示其他编码。

  • 提交日志消息通常以 UTF-8 编码,但也支持其他扩展 ASCII 编码。这包括 ISO-8859-x,CP125x 和许多其他,但 _ 不是 _ UTF-16/32,EBCDIC 和 CJK 多字节编码(GBK,Shift-JIS,Big5,EUC-x,CP9xx 等。 )。

虽然我们鼓励提交日志消息以 UTF-8 编码,但核心和 Git 瓷器都不是为了强制项目使用 UTF-8。如果特定项目的所有参与者发现使用遗留编码更方便,Git 不会禁止它。但是,有一些事情需要牢记。

  1. git commitgit commit-tree 发出警告,如果提供给它的提交日志消息看起来不像有效的 UTF-8 字符串,除非你明确说你的项目使用了遗产编码。说这个的方法是在.git/config文件中使用 i18n.commitencoding,如下所示:

    [i18n]
    	commitEncoding = ISO-8859-1
    

    使用上述设置创建的提交对象在其encoding标题中记录i18n.commitEncoding的值。这是为了帮助其他人以后再看。缺少此标头意味着提交日志消息以 UTF-8 编码。

  2. git loggit showgit blame 和朋友们查看提交对象的encoding头,并尝试将日志消息重新编码为除非另有说明,否则为 UTF-8。您可以使用.git/config文件中的i18n.logOutputEncoding指定所需的输出编码,如下所示:

    [i18n]
    	logOutputEncoding = ISO-8859-1
    

    如果您没有此配置变量,则使用i18n.commitEncoding的值。

请注意,我们故意选择在提交以在提交对象级别强制使用 UTF-8 时不重新编写提交日志消息,因为重新编码为 UTF-8 不一定是可逆操作。

FILES

在/ etc /邮件名

也可以看看

git-write-tree [1]

GIT

部分 git [1] 套件

git-count-objects

原文: git-scm.com/docs/git-count-objects

名称

git-count-objects - 计算解压缩的对象数及其磁盘消耗

概要

git count-objects [-v] [-H | --human-readable]

描述

这会计算解压缩的目标文件的数量和它们消耗的磁盘空间,以帮助您确定何时是重新打包的好时机。

OPTIONS

 -v 
 --verbose 

报告更详细:

count:松散物体的数量

size:松散对象消耗的磁盘空间,以 KiB 为单位(除非指定了-H)

in-pack:包内对象的数量

size-pack:包消耗的磁盘空间,以 KiB 为单位(除非指定了-H)

prune-packable:包中也存在的松散物体的数量。可以使用git prune-packed修剪这些对象。

garbage:对象数据库中既不是有效的松散对象也不是有效包的文件数

size-garbage:垃圾文件占用的磁盘空间,以 KiB 为单位(除非指定-H)

alternate:备用对象数据库的绝对路径;可能会出现多次,每条路径一行。请注意,如果路径包含不可打印的字符,则它可能被双引号括起来并包含 C 样式的反斜杠转义序列。

 -H 
 --human-readable 

以人类可读格式打印尺寸

GIT

部分 git [1] 套件

git-diff-index

原文: git-scm.com/docs/git-diff-index

名称

git-diff-index - 将树与工作树或索引进行比较

概要

git diff-index [-m] [--cached] [<common diff options>] <tree-ish> [<path>…​]

描述

将树对象中找到的 blob 的内容和模式与工作树中相应的跟踪文件或索引中的相应路径进行比较。当< path>存在参数,仅比较与这些模式匹配的路径。否则,将比较所有跟踪的文件。

OPTIONS

 -p 
 -u 
 --patch 

生成补丁(请参阅生成补丁的部分)。

 -s 
 --no-patch 

抑制差异输出。对于git show等默认显示补丁的命令,或取消--patch的效果很有用。

 -U<n> 
 --unified=<n> 

用< n>生成差异。上下文而不是通常的三行。意味着-p

 --raw 

以原始格式生成 diff。这是默认值。

 --patch-with-raw 

-p --raw的同义词。

 --indent-heuristic 

启用改变差异块边界的启发式以使补丁更易于阅读。这是默认值。

 --no-indent-heuristic 

禁用缩进启发式。

 --minimal 

花些额外的时间来确保产生尽可能小的差异。

 --patience 

使用“耐心差异”算法生成差异。

 --histogram 

使用“histogram diff”算法生成 diff。

 --anchored=<text> 

使用“锚定差异”算法生成差异。

可以多次指定此选项。

如果源和目标中都存在一行,只存在一次,并以此文本开头,则此算法会尝试阻止它在输出中显示为删除或添加。它在内部使用“耐心差异”算法。

 --diff-algorithm={patience|minimal|histogram|myers} 

选择差异算法。变体如下:

 default, myers 

基本的贪心差异算法。目前,这是默认值。

 minimal 

花些额外的时间来确保产生尽可能小的差异。

 patience 

生成补丁时使用“耐心差异”算法。

 histogram 

该算法将耐心算法扩展为“支持低发生的共同元素”。

例如,如果将diff.algorithm变量配置为非默认值并想要使用默认值,则必须使用--diff-algorithm=default选项。

 --stat[=<width>[,<name-width>[,<count>]]] 

生成 diffstat。默认情况下,文件名部分将使用必要的空间,图形部分的其余部分将使用。最大宽度默认为终端宽度,如果未连接到终端,则为 80 列,并且可以被&lt;width&gt;覆盖。可以通过在逗号后面给出另一个宽度&lt;name-width&gt;来限制文件名部分的宽度。可以使用--stat-graph-width=&lt;width&gt;(影响生成统计图的所有命令)或设置diff.statGraphWidth=&lt;width&gt;(不影响git format-patch)来限制图形部分的宽度。通过给出第三个参数&lt;count&gt;,可以将输出限制为第一个&lt;count&gt;行,如果有更多,则可以将...限制为...

也可以使用--stat-width=&lt;width&gt;--stat-name-width=&lt;name-width&gt;--stat-count=&lt;count&gt;单独设置这些参数。

 --compact-summary 

输出扩展标题信息的精简摘要,例如文件创建或删除(“新”或“消失”,如果是符号链接,则可选“+ l”)和模式更改(“+ x”或“-x”用于添加或删除 diffstat 中的可执行位)。信息放在文件名部分和图形部分之间。意味着--stat

 --numstat 

--stat类似,但显示十进制表示法中添加和删除的行数以及没有缩写的路径名,以使其更加机器友好。对于二进制文件,输出两个-而不是0 0

 --shortstat 

仅输出--stat格式的最后一行,其中包含已修改文件的总数,以及已添加和已删除行的数量。

 --dirstat[=<param1,param2,…​>] 

输出每个子目录的相对更改量的分布。 --dirstat的行为可以通过以逗号分隔的参数列表传递来定制。默认值由diff.dirstat配置变量控制(参见 git-config [1] )。可以使用以下参数:

 changes 

通过计算已从源中删除或添加到目标的行来计算 dirstat 数。这忽略了文件中纯代码移动的数量。换句话说,重新排列文件中的行不会像其他更改那样计算。这是没有给出参数时的默认行为。

 lines 

通过执行常规的基于行的差异分析来计算 dirstat 数字,并对移除/添加的行数进行求和。 (对于二进制文件,计算 64 字节块,因为二进制文件没有自然的线条概念)。这是比changes行为更昂贵的--dirstat行为,但它确实计算文件中重新排列的行与其他更改一样多。结果输出与您从其他--*stat选项获得的输出一致。

 files 

通过计算更改的文件数来计算 dirstat 数。在 dirstat 分析中,每个更改的文件都相同。这是计算上最便宜的--dirstat行为,因为它根本不需要查看文件内容。

 cumulative 

计算父目录的子目录中的更改。请注意,使用cumulative时,报告的百分比总和可能超过 100%。可以使用noncumulative参数指定默认(非累积)行为。

 <limit> 

整数参数指定截止百分比(默认为 3%)。贡献低于此百分比变化的目录不会显示在输出中。

示例:以下将计算已更改的文件,同时忽略少于已更改文件总量的 10%的目录,并在父目录中累计子目录计数:--dirstat=files,10,cumulative

 --summary 

输出扩展标题信息的精简摘要,例如创建,重命名和模式更改。

 --patch-with-stat 

-p --stat的同义词。

 -z 

当给出--raw--numstat--name-only--name-status时,不要使用路径名并使用 NUL 作为输出字段终止符。

如果没有此选项,则会引用具有“异常”字符的路径名,如配置变量core.quotePath所述(参见 git-config [1] )。

 --name-only 

仅显示已更改文件的名称。

 --name-status 

仅显示已更改文件的名称和状态。有关状态字母的含义,请参阅--diff-filter选项的说明。

 --submodule[=<format>] 

指定子模块的差异如何显示。指定--submodule=short时,使用 _ 短 _ 格式。此格式仅显示范围开头和结尾的提交名称。指定--submodule--submodule=log时,使用 log 格式。此格式列出 git-submodule [1] summary等范围内的提交。指定--submodule=diff时,使用 diff 格式。此格式显示提交范围之间子模块内容更改的内联差异。如果未设置配置选项,则默认为diff.submodule或 _ 短 _ 格式。

 --color[=<when>] 

显示彩色差异。 --color(即没有 =<当> )与--color=always相同时。 < when> 可以是alwaysneverauto之一。

 --no-color 

关掉彩色差异。它与--color=never相同。

 --color-moved[=<mode>] 

移动的代码行的颜色不同。 <模式>如果没有给出选项,默认为 no ,如果给出没有模式的选项,则默认为 zebra 。模式必须是以下之一:

 no 

移动的线条不会突出显示。

 default 

zebra的同义词。这可能会在未来转变为更明智的模式。

 plain 

在一个位置添加并在另一个位置删除的任何行都将使用 color.diff.newMoved 进行着色。类似地, color.diff.oldMoved 将用于在 diff 中的其他位置添加的已删除行。此模式选择任何已移动的行,但在检查中确定是否在没有置换的情况下移动了代码块时,它不是很有用。

 blocks 

贪婪地检测至少 20 个字母数字字符的移动文本块。使用 color.diff。{old,new} Moved 颜色绘制检测到的块。相邻的街区不能分开。

 zebra 

在 _ 块 _ 模式中检测移动文本块。使用 color.diff。{old,new} Moved 颜色或 color.diff。{old,new} MovedAlternative 绘制块。两种颜色之间的变化表示检测到新的块。

 dimmed-zebra 

zebra 类似,但执行了移动代码的无趣部分的额外调暗。两个相邻街区的边界线被认为是有趣的,其余的是无趣的。 dimmed_zebra是不推荐使用的同义词。

 --no-color-moved 

关闭移动检测。这可用于覆盖配置设置。它与--color-moved=no相同。

 --color-moved-ws=<modes> 

这将配置在执行--color-moved的移动检测时如何忽略空白。这些模式可以以逗号分隔的列表给出:

 no 

执行移动检测时不要忽略空格。

 ignore-space-at-eol 

忽略 EOL 中的空白更改。

 ignore-space-change 

忽略空格量的变化。这会忽略行尾的空格,并将一个或多个空白字符的所有其他序列视为等效。

 ignore-all-space 

比较线条时忽略空格。即使一行有空格而另一行没有空格,这也会忽略差异。

 allow-indentation-change 

最初忽略移动检测中的任何空格,然后如果每行的空白变化相同,则仅将移动的代码块分组到块中。这与其他模式不兼容。

 --no-color-moved-ws 

执行移动检测时不要忽略空格。这可用于覆盖配置设置。它与--color-moved-ws=no相同。

 --word-diff[=<mode>] 

使用< mode>显示单词 diff。划定改变的单词。默认情况下,单词由空格分隔;见下面的--word-diff-regex。 <模式>默认为 plain ,必须是以下之一:

 color 

仅使用颜色突出显示更改的单词。意味着--color

 plain 

将单词显示为[-removed-]{+added+}。如果它们出现在输入中,则不会尝试转义分隔符,因此输出可能不明确。

 porcelain 

使用特殊的基于行的格式用于脚本使用。添加/删除/未更改的运行以通常的统一 diff 格式打印,从行开头的+ / - /``字符开始并延伸到行尾。输入中的换行符由其自身行上的波浪号~表示。

 none 

再次禁用字差异。

请注意,尽管第一个模式的名称,但如果启用了颜色,则使用颜色突出显示所有模式中已更改的部分。

 --word-diff-regex=<regex> 

使用< regex>决定一个单词是什么,而不是将非空格的运行视为一个单词。除非已经启用,否则还暗示--word-diff

< regex>的每个非重叠匹配被认为是一个词。这些匹配之间的任何内容都被视为空格并被忽略(!)以查找差异。您可能希望将|[^[:space:]]附加到正则表达式,以确保它匹配所有非空白字符。包含换行符的匹配项会在换行符处以静默方式截断(!)。

例如,--word-diff-regex=.会将每个字符视为一个单词,并相应地逐个字符地显示差异。

正则表达式也可以通过 diff 驱动程序或配置选项设置,参见 gitattributes [5]git-config [1] 。明确地覆盖任何差异驱动程序或配置设置。 Diff 驱动程序覆盖配置设置。

 --color-words[=<regex>] 

相当于--word-diff=color加(如果指定了正则表达式)--word-diff-regex=&lt;regex&gt;

 --no-renames 

关闭重命名检测,即使配置文件提供默认值也是如此。

 --check 

如果更改引入冲突标记或空白错误,则发出警告。什么被认为是空白错误由core.whitespace配置控制。默认情况下,尾随空格(包括仅由空格组成的行)和在行的初始缩进内紧跟着制表符的空格字符被视为空格错误。如果发现问题,则退出非零状态。与--exit-code 不兼容。

 --ws-error-highlight=<kind> 

突出显示差异的contextoldnew行中的空白错误。多个值用逗号分隔,none重置先前的值,default将列表重置为newallold,new,context的简写。如果未指定此选项,并且未设置配置变量diff.wsErrorHighlight,则仅突出显示new行中的空白错误。空白错误用color.diff.whitespace着色。

 --full-index 

在生成补丁格式输出时,在“索引”行上显示完整的前映像和后映像 blob 对象名称,而不是第一个字符。

 --binary 

--full-index外,还可输出可用git-apply应用的二进制差异。

 --abbrev[=<n>] 

而不是在 diff-raw 格式输出和 diff-tree 标题行中显示完整的 40 字节十六进制对象名称,而是仅显示部分前缀。这与上面的--full-index选项无关,后者控制 diff-patch 输出格式。可以使用--abbrev=&lt;n&gt;指定非默认位数。

 -B[<n>][/<m>] 
 --break-rewrites[=[<n>][/<m>]] 

将完整的重写更改分为删除和创建对。这有两个目的:

它影响了一个更改的方式,相当于一个文件的完全重写,而不是一系列的删除和插入混合在一起,只有几行恰好与文本作为上下文匹配,而是作为单个删除所有旧的后跟一个单个插入所有新内容,数字m控制-B 选项的这一方面(默认为 60%)。 -B/70%指定少于 30%的原始文本应保留在结果中,以便 Git 将其视为完全重写(即,否则生成的修补程序将是一系列删除和插入与上下文行混合在一起)。

当与-M 一起使用时,完全重写的文件也被视为重命名的源(通常-M 只考虑作为重命名源消失的文件),并且数字n控制 - 的这方面 - B 选项(默认为 50%)。 -B20%指定添加和删除的更改与文件大小的 20%或更多相比,有资格被选为可能的重命名源到另一个文件。

 -M[<n>] 
 --find-renames[=<n>] 

检测重命名。如果指定了n,则它是相似性指数的阈值(即与文件大小相比的添加/删除量)。例如,-M90%表示如果超过 90%的文件未更改,Git 应将删除/添加对视为重命名。如果没有%符号,则该数字将作为分数读取,并在其前面加上小数点。即,-M5变为 0.5,因此与-M50%相同。同样,-M05-M5%相同。要将检测限制为精确重命名,请使用-M100%。默认相似性指数为 50%。

 -C[<n>] 
 --find-copies[=<n>] 

检测副本以及重命名。另见--find-copies-harder。如果指定了n,则其含义与-M&lt;n&gt;的含义相同。

 --find-copies-harder 

出于性能原因,默认情况下,仅当在同一变更集中修改了副本的原始文件时,-C选项才会查找副本。此标志使命令检查未修改的文件作为副本源的候选者。对于大型项目来说,这是一项非常昂贵的操作,因此请谨慎使用。提供多个-C选项具有相同的效果。

 -D 
 --irreversible-delete 

省略删除的原像,即只打印标题而不打印原像和/dev/null之间的差异。得到的贴片不适用于patchgit apply;这仅适用于那些希望在更改后专注于审阅文本的人。此外,输出显然缺乏足够的信息来反向应用这样的补丁,甚至手动,因此选项的名称。

-B一起使用时,也省略删除/创建对的删除部分中的原像。

 -l<num> 

-M-C选项需要 O(n ^ 2)处理时间,其中 n 是潜在的重命名/复制目标的数量。如果重命名/复制目标的数量超过指定的数量,此选项可防止重命名/复制检测运行。

 --diff-filter=[(A|C|D|M|R|T|U|X|B)…​[*]] 

仅选择已添加(A),复制(C),已删除(D),已修改(M),已重命名(R)的文件,其类型(即常规文件,符号链接,子模块,...)更改(T),未合并(U),未知(X),或已配对破碎(B)。可以使用过滤器字符的任何组合(包括无)。当*(全部或全部)添加到组合中时,如果有任何文件与比较中的其他条件匹配,则选择所有路径;如果没有与其他条件匹配的文件,则不会选择任何内容。

此外,这些大写字母可以降级为排除。例如。 --diff-filter=ad排除添加和删除的路径。

请注意,并非所有差异都可以包含所有类型。例如,从索引到工作树的差异永远不会有添加条目(因为差异中包含的路径集受限于索引中的内容)。同样,如果禁用了对这些类型的检测,则无法显示复制和重命名的条目。

 -S<string> 

查找改变文件中指定字符串出现次数(即添加/删除)的差异。用于脚本编写者的使用。

当你正在寻找一个确切的代码块(比如一个结构体)时,它很有用,并且想要知道该块首次出现以来的历史:迭代地使用该特征将原始图像中的有趣块反馈回-S,继续前进,直到你获得该块的第一个版本。

也搜索二进制文件。

 -G<regex> 

查找补丁文本包含与< regex>匹配的添加/删除行的差异。

为了说明-S&lt;regex&gt; --pickaxe-regex-G&lt;regex&gt;之间的区别,请考虑在同一文件中使用以下 diff 进行提交:

+    return !regexec(regexp, two->ptr, 1, &regmatch, 0);
...
-    hit = !regexec(regexp, mf2.ptr, 1, &regmatch, 0);

虽然git log -G"regexec\(regexp"将显示此提交,但git log -S"regexec\(regexp" --pickaxe-regex不会(因为该字符串的出现次数没有改变)。

除非提供--text,否则将忽略没有 textconv 过滤器的二进制文件的补丁。

有关详细信息,请参阅 gitdiffcore [7] 中的 pickaxe 条目。

 --find-object=<object-id> 

查找更改指定对象出现次数的差异。与-S类似,只是参数的不同之处在于它不搜索特定的字符串,而是搜索特定的对象 id。

该对象可以是 blob 或子模块提交。它意味着git-log中的-t选项也可以找到树。

 --pickaxe-all 

-S-G找到更改时,显示该更改集中的所有更改,而不仅仅是包含< string>中更改的文件。

 --pickaxe-regex 

对待< string>赋予-S作为扩展的 POSIX 正则表达式以匹配。

 -O<orderfile> 

控制文件在输出中的显示顺序。这会覆盖diff.orderFile配置变量(参见 git-config [1] )。要取消diff.orderFile,请使用-O/dev/null

输出顺序由< orderfile>中的 glob 模式的顺序决定。首先输出所有与第一个模式匹配的路径名的文件,然后输出所有与第二个模式(但不是第一个模式)匹配的路径名的文件,依此类推。路径名与任何模式都不匹配的所有文件都是最后输出的,就好像文件末尾有一个隐式匹配所有模式一样。如果多个路径名具有相同的等级(它们匹配相同的模式但没有早期模式),则它们相对于彼此的输出顺序是正常顺序。

< orderfile>解析如下:

  • 空行被忽略,因此可以将它们用作分隔符以提高可读性。

  • 以哈希(“#”)开头的行将被忽略,因此它们可用于注释。如果以散列开头,则将反斜杠(“\”)添加到模式的开头。

  • 每个其他行包含一个模式。

模式与没有 FNM_PATHNAME 标志的 fnmatch(3)使用的模式具有相同的语法和语义,但如果删除任意数量的最终路径名组件与模式匹配,则路径名也匹配模式。例如,模式“foo*bar”匹配“fooasdfbar”和“foo/bar/baz/asdf”而不匹配“foobarx”。

 -R 

交换两个输入;也就是说,显示从索引或磁盘文件到树内容的差异。

 --relative[=<path>] 

从项目的子目录运行时,可以告诉它排除目录外的更改并使用此选项显示相对于它的路径名。当您不在子目录中时(例如,在裸存储库中),您可以通过给出< path>来命名哪个子目录以使输出相对。作为一个论点。

 -a 
 --text 

将所有文件视为文本。

 --ignore-cr-at-eol 

进行比较时,忽略行尾的回车。

 --ignore-space-at-eol 

忽略 EOL 中的空白更改。

 -b 
 --ignore-space-change 

忽略空格量的变化。这会忽略行尾的空格,并将一个或多个空白字符的所有其他序列视为等效。

 -w 
 --ignore-all-space 

比较线条时忽略空格。即使一行有空格而另一行没有空格,这也会忽略差异。

 --ignore-blank-lines 

忽略其行全部为空的更改。

 --inter-hunk-context=<lines> 

显示差异之间的上下文,直到指定的行数,从而融合彼此接近的帅哥。如果未设置配置选项,则默认为diff.interHunkContext或 0。

 -W 
 --function-context 

显示整个周围的变化功能。

 --exit-code 

使用类似于 diff(1)的代码退出程序。也就是说,如果存在差异则退出 1,0 表示没有差异。

 --quiet 

禁用程序的所有输出。意味着--exit-code

 --ext-diff 

允许执行外部 diff 助手。如果使用 gitattributes [5] 设置外部差异驱动程序,则需要将此选项与 git-log [1] 和朋友一起使用。

 --no-ext-diff 

禁止外部差异驱动程序。

 --textconv 
 --no-textconv 

在比较二进制文件时允许(或禁止)外部文本转换过滤器运行。有关详细信息,请参阅 gitattributes [5] 。由于 textconv 过滤器通常是单向转换,因此生成的差异适合人类使用,但无法应用。因此,默认情况下,textconv 过滤器仅针对 git-diff [1]git-log [1] 启用,但不适用于 git-format-patch [ 1] 或差异管道命令。

 --ignore-submodules[=<when>] 

忽略差异生成中子模块的更改。 <当>可以是“none”,“untracked”,“dirty”或“all”,这是默认值。使用“none”时,如果子模块包含未跟踪或修改的文件,或者其 HEAD 与超级项目中记录的提交不同,则可以使用“无”来修改子模块,并可用于覆盖ignore 选项的任何设置 git-config [1]gitmodules [5] 。当使用“未跟踪”时,如果子模块仅包含未跟踪的内容(但仍会扫描修改的内容),则子模块不会被视为脏。使用“脏”忽略对子模块工作树的所有更改,仅显示存储在超级项目中的提交的更改(这是 1.7.0 之前的行为)。使用“all”隐藏子模块的所有更改。

 --src-prefix=<prefix> 

显示给定的源前缀而不是“a /”。

 --dst-prefix=<prefix> 

显示给定的目标前缀而不是“b /”。

 --no-prefix 

不显示任何源或目标前缀。

 --line-prefix=<prefix> 

为每行输出预先附加前缀。

 --ita-invisible-in-index 

默认情况下,“git add -N”添加的条目在“git diff”中显示为现有空文件,在“git diff --cached”中显示为新文件。此选项使条目在“git diff”中显示为新文件,在“git diff --cached”中不存在。可以使用--ita-visible-in-index恢复此选项。这两个选项都是实验性的,将来可以删除。

有关这些常用选项的更详细说明,另请参阅 gitdiffcore [7]

 <tree-ish> 

要反对的树对象的 id。

 --cached 

根本不考虑磁盘上的文件

 -m 

默认情况下,索引中记录但未签出的文件将报告为已删除。该标志使 git diff-index 表示所有未签出的文件都是最新的。

原始输出格式

来自“git-diff-index”,“git-diff-tree”,“git-diff-files”和“git diff -raw”的原始输出格式非常相似。

这些命令都比较了两组东西;比较的不同之处是:

 git-diff-index <tree-ish> 

比较< tree-ish>以及文件系统上的文件。

 git-diff-index --cached <tree-ish> 

比较< tree-ish>和索引。

 git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>…​] 

比较两个参数命名的树。

 git-diff-files [<pattern>…​] 

比较索引和文件系统上的文件。

“git-diff-tree”命令通过打印正在比较的内容的哈希来开始输出。之后,所有命令都会为每个更改的文件打印一个输出行。

输出行以这种方式格式化:

in-place edit  :100644 100644 bcd1234 0123456 M file0
copy-edit      :100644 100644 abcd123 1234567 C68 file1 file2
rename-edit    :100644 100644 abcd123 1234567 R86 file1 file3
create         :000000 100644 0000000 1234567 A file4
delete         :100644 000000 1234567 0000000 D file5
unmerged       :000000 000000 0000000 0000000 U file6

也就是说,从左到右:

  1. 一个冒号。

  2. “src”模式;如果创建或未合并,则为 000000。

  3. 空间。

  4. “dst”模式;如果删除或未合并,则为 000000。

  5. 空间。

  6. sha1 为“src”; 0 {40}如果创建或未合并。

  7. 空间。

  8. sha1 为“dst”; 0 {40}如果创建,未合并或“查看工作树”。

  9. 空间。

  10. 状态,后跟可选的“分数”编号。

  11. 使用-z选项时的选项卡或 NUL。

  12. “src”的路径

  13. 使用-z选项时的选项卡或 NUL;仅适用于 C 或 R.

  14. “dst”的路径;仅适用于 C 或 R.

  15. 使用-z选项时,LF 或 NUL 终止记录。

可能的状态字母是:

  • 答:添加文件

  • C:将文件复制到新文件中

  • D:删除文件

  • M:修改文件的内容或模式

  • R:重命名文件

  • T:更改文件类型

  • U:文件已取消合并(您必须先完成合并才能提交)

  • X:“未知”更改类型(最有可能是错误,请报告)

状态字母 C 和 R 后面总是跟一个分数(表示移动或复制的源和目标之间的相似性百分比)。状态字母 M 之后可以是文件重写的分数(表示不相似的百分比)。

< SHA1>如果文件系统上的文件是新文件并且它与索引不同步,则显示为全 0。

例:

:100644 100644 5be4a4a 0000000 M file.c

如果没有-z选项,则会引用具有“异常”字符的路径名,如配置变量core.quotePath所述(参见 git-config [1] )。使用-z,文件名逐字输出,行以 NUL 字节终止。

用于合并的 diff 格式

“git-diff-tree”,“git-diff-files”和“git-diff --raw”可以使用-c--cc选项为合并提交生成 diff 输出。输出与上述格式的不同之处如下:

  1. 每个父母都有一个冒号

  2. 还有更多“src”模式和“src”sha1

  3. status 是每个父级的连接状态字符

  4. 没有可选的“得分”号码

  5. 单路径,仅适用于“dst”

例:

::100644 100644 100644 fabadb8 cc95eb0 4866510 MM	describe.c

请注意,_ 组合 diff_ 仅列出从所有父项修改的文件。

使用-p 生成补丁

当“git-diff-index”,“git-diff-tree”或“git-diff-files”使用-p选项运行时,“git diff”不带--raw选项或“git log”使用“-p”选项,它们不会产生上述输出;相反,他们生成一个补丁文件。您可以通过GIT_EXTERNAL_DIFFGIT_DIFF_OPTS环境变量自定义此类修补程序的创建。

-p 选项产生的内容与传统的 diff 格式略有不同:

  1. 它前面有一个“git diff”标题,如下所示:

    diff --git a/file1 b/file2
    

    除非涉及重命名/复制,否则a/b/文件名是相同的。特别是,即使是创建或删除,/dev/null也是 _ 而不是 _ 来代替a/b/文件名。

    当涉及重命名/复制时,file1file2分别显示重命名/复制的源文件的名称和重命名/复制的文件的名称。

  2. 它后跟一个或多个扩展标题行:

    old mode &lt;mode&gt;
    new mode &lt;mode&gt;
    deleted file mode &lt;mode&gt;
    new file mode &lt;mode&gt;
    copy from &lt;path&gt;
    copy to &lt;path&gt;
    rename from &lt;path&gt;
    rename to &lt;path&gt;
    similarity index &lt;number&gt;
    dissimilarity index &lt;number&gt;
    index &lt;hash&gt;..&lt;hash&gt; &lt;mode&gt;
    

    文件模式打印为 6 位八进制数,包括文件类型和文件权限位。

    扩展标头中的路径名不包括a/b/前缀。

    相似性指数是未更改行的百分比,相异性指数是更改行的百分比。它是一个向下舍入的整数,后跟一个百分号。因此,100%的相似性索引值保留用于两个相等的文件,而 100%的相异性意味着旧文件中的任何行都不会成为新文件。

    索引行包括更改前后的 SHA-1 校验和。 <模式>如果文件模式没有改变,则包括在内;否则,单独的行表示旧模式和新模式。

  3. 具有“异常”字符的路径名被引用,如配置变量core.quotePath所述(参见 git-config [1] )。

  4. 输出中的所有file1文件在提交之前引用文件,并且所有file2文件在提交之后引用文件。将每个更改顺序应用于每个文件是不正确的。例如,此补丁将交换 a 和 b:

    diff --git a/a b/b
    rename from a
    rename to b
    diff --git a/b b/a
    rename from b
    rename to a
    

组合差异格式

在显示合并时,任何差异生成命令都可以使用-c--cc选项生成 _ 组合差异 _。当显示与 git-diff [1]git-show [1] 的合并时,这是默认格式。另请注意,您可以为这些命令中的任何一个提供-m选项,以强制使用合并的各个父项生成差异。

_ 组合 diff_ 格式如下所示:

diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
	return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
  }

- static void describe(char *arg)
 -static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
  {
 +	unsigned char sha1[20];
 +	struct commit *cmit;
	struct commit_list *list;
	static int initialized = 0;
	struct commit_name *n;

 +	if (get_sha1(arg, sha1) < 0)
 +		usage(describe_usage);
 +	cmit = lookup_commit_reference(sha1);
 +	if (!cmit)
 +		usage(describe_usage);
 +
	if (!initialized) {
		initialized = 1;
		for_each_ref(get_name);
  1. 它前面有一个“git diff”标题,看起来像这样(当使用-c选项时):

    diff --combined file
    

    或者像这样(当使用--cc选项时):

    diff --cc file
    
  2. 它后跟一个或多个扩展标题行(此示例显示了与两个父项的合并):

    index &lt;hash&gt;,&lt;hash&gt;..&lt;hash&gt;
    mode &lt;mode&gt;,&lt;mode&gt;..&lt;mode&gt;
    new file mode &lt;mode&gt;
    deleted file mode &lt;mode&gt;,&lt;mode&gt;
    

    只有当< mode>中的至少一个出现时,mode &lt;mode&gt;,&lt;mode&gt;..&lt;mode&gt;行才会出现。与其他人不同。具有关于检测到的内容移动(重命名和复制检测)的信息的扩展标题被设计为与两个< tree-ish>的差异一起工作。并且不会被组合 diff 格式使用。

  3. 接下来是两行的文件/文件头

    --- a/file
    +++ b/file
    

    与传统 _ 统一 _ diff 格式的双行标题类似,/dev/null用于表示创建或删除的文件。

  4. 修改了块头格式以防止人们意外地将其馈送到patch -p1。创建组合差异格式用于审查合并提交更改,并不适用于应用。此更改类似于扩展 _ 索引 _ 标头中的更改:

    @@@ &lt;from-file-range&gt; &lt;from-file-range&gt; &lt;to-file-range&gt; @@@
    

    组合 diff 格式的块头中有(父项数+ 1)@个字符。

与传统的 _ 统一 _ 差异格式不同,后者显示两个文件 A 和 B,其中一列具有-(减去 - 出现在 A 中但在 B 中删除),+(加 - 缺少 A 但是添加到 B)或" "(空格 - 未更改)前缀,此格式将两个或多个文件 file1,file2,...与一个文件 X 进行比较,并显示 X 与每个文件 N 的不同之处。每个 fileN 的一列被添加到输出行之前,以指示 X 的行与它的不同之处。

N 列中的-字符表示该行出现在 fileN 中,但它不会出现在结果中。列 N 中的+字符表示该行出现在结果中,而 fileN 没有该行(换句话说,从该父项的角度添加了该行)。

在上面的示例输出中,函数签名已从两个文件中更改(因此,file1 和 file2 中的两个-删除加上++表示添加的一行未出现在 file1 或 file2 中)。另外八行与 file1 相同,但不出现在 file2 中(因此以+为前缀)。

当由git diff-tree -c显示时,它将合并提交的父项与合并结果进行比较(即 file1..fileN 是父项)。当由git diff-files -c显示时,它将两个未解析的合并父项与工作树文件进行比较(即 file1 是阶段 2 又名“我们的版本”,file2 是阶段 3 又名“他们的版本”)。

其他差异格式

--summary选项描述新添加,删除,重命名和复制的文件。 --stat选项将 diffstat(1)图形添加到输出。这些选项可以与其他选项结合使用,例如-p,用于人类消费。

当显示涉及重命名或副本的更改时,--stat输出通过组合路径名的公共前缀和后缀来紧凑地格式化路径名。例如,修改 4 行时将arch/i386/Makefile移动到arch/x86/Makefile的更改将显示如下:

arch/{i386 => x86}/Makefile    |   4 +--

--numstat选项提供 diffstat(1)信息,但设计用于更容易的机器消耗。 --numstat输出中的条目如下所示:

1	2	README
3	1	arch/{i386 => x86}/Makefile

也就是说,从左到右:

  1. 添加的行数;

  2. 标签;

  3. 删除的行数;

  4. 标签;

  5. pathname(可能带有重命名/复制信息);

  6. 换行符。

-z输出选项生效时,输出格式为:

1	2	README NUL
3	1	NUL arch/i386/Makefile NUL arch/x86/Makefile NUL

那是:

  1. 添加的行数;

  2. 标签;

  3. 删除的行数;

  4. 标签;

  5. NUL(仅在重命名/复制时存在);

  6. 原像中的路径名;

  7. NUL(仅在重命名/复制时存在);

  8. postimage 中的路径名(仅在重命名/复制时存在);

  9. 一个 NUL。

在重命名的情况下,preimage 路径之前的额外NUL是允许读取输出的脚本判断正在读取的当前记录是单路径记录还是重命名/复制记录而无需提前读取。读取添加和删除的行后,读取NUL将产生路径名,但如果是NUL,则记录将显示两个路径。

运营模式

您可以选择是否完全信任索引文件(使用--cached标志)或要求 diff 逻辑显示任何与 stat 状态不匹配的文件为“暂时更改”。这两项操作确实非常有用。

缓存模式

如果指定了--cached,则可以询问:

show me the differences between HEAD and the current index
contents (the ones I'd write using 'git write-tree')

例如,假设您已经处理了工作目录,更新了索引中的一些文件并准备提交。你想要确切地看到你将提交什么,而不必编写新的树对象并以这种方式进行比较,为此,你只需要做

git diff-index --cached HEAD

示例:假设我已将commit.c重命名为git-commit.c,并且我已经完成了update-index以使其在索引文件中生效。 git diff-files根本不会显示任何内容,因为索引文件与我的工作目录匹配。但是做一个 git diff-index 会:

torvalds@ppc970:~/git> git diff-index --cached HEAD
-100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        commit.c
+100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        git-commit.c

你可以很容易地看到以上是重命名。

实际上,git diff-index --cached 应该总是完全等同于实际执行 _git 写树 _ 并进行比较。除了这个,你只想检查你的位置的情况要好得多。

因此,当你问自己“我已经标记了什么以及与之前的树有什么区别”时,做一个git diff-index --cached基本上非常有用。

非缓存模式

“非缓存”模式采用不同的方法,并且可能更有用,因为它的作用不能用 git write-tree + _git diff-模拟树 _。这就是默认模式。非缓存版本会询问以下问题:

show me the differences between HEAD and the currently checked out
tree - index contents _and_ files that aren't up to date

这显然是一个非常有用的问题,因为它告诉你可以提交什么。同样,输出将 git diff-tree -r 输出与 tee 匹配,但有一个扭曲。

扭曲的是,如果某个文件与索引不匹配,我们就没有后备存储的东西,我们使用神奇的“全零”sha1 来表示。所以,假设你已经编辑了kernel/sched.c,但实际上还没有对它进行 git update-index - 没有与新状态相关的“对象”,你得到:

torvalds@ppc970:~/v2.6/linux> git diff-index --abbrev HEAD
:100644 100664 7476bb... 000000...      kernel/sched.c

即,它表明树已经改变,kernel/sched.c不是最新的,可能包含新的东西。全零 sha1 意味着要获得真正的差异,您需要直接查看工作目录中的对象,而不是执行对象到对象的差异。

| 注意 | 与此类型的其他命令一样, git diff-index 实际上根本不查看文件的内容。所以也许kernel/sched.c实际上并没有改变,只是你碰到了它。在任何一种情况下,都需要注意 git update-index 才能使索引同步。 |

| 注意 | 您可以将文件混合显示为“已更新”和“在工作目录中仍然是脏的”。您总是可以告诉哪个文件处于哪个状态,因为“已更新”的文件显示有效的 sha1,而“与索引不同步”的文件将始终具有特殊的全零值 sha1。 |

GIT

部分 git [1] 套件

git-for-each-ref

原文: git-scm.com/docs/git-for-each-ref

名称

git-for-each-ref - 每个参考的输出信息

概要

git for-each-ref [--count=<count>] [--shell|--perl|--python|--tcl]
		   [(--sort=<key>)…​] [--format=<format>] [<pattern>…​]
		   [--points-at=<object>]
		   (--merged[=<object>] | --no-merged[=<object>])
		   [--contains[=<object>]] [--no-contains[=<object>]]

描述

迭代匹配&lt;pattern&gt;的所有引用并根据给定的&lt;format&gt;显示它们,然后根据给定的&lt;key&gt;集对它们进行排序。如果给出&lt;count&gt;,则在显示许多参考后停止。 &lt;format&gt;中的插值可以选择引用指定主语言中的字符串文字,允许直接用该语言进行评估。

OPTIONS

 <pattern>…​ 

如果给出一个或多个模式,则仅显示与至少一个模式匹配的 refs,使用 fnmatch(3)或字面意思,在后一种情况下完全匹配或从开头到斜线。

 --count=<count> 

默认情况下,该命令显示与&lt;pattern&gt;匹配的所有引用。此选项使其在显示许多引用后停止。

 --sort=<key> 

要排序的字段名称。前缀-按值的降序排序。未指定时,使用refname。您可以使用--sort =< key>选项多次,在这种情况下,最后一个键成为主键。

 --format=<format> 

一个字符串,用于插入显示的 ref 及其指向的对象的%(fieldname)。如果fieldname以星号(*为前缀)并且 ref 指向标记对象,请使用标记对象引用的对象中的字段值(而不是标记对象中的字段)。未指定时,&lt;format&gt;默认为%(objectname) SPC %(objecttype) TAB %(refname)。它还将%%插入到%%xx其中xx是十六进制数字,插入到十六进制代码xx的字符中;例如%00内插到\0(NUL),%09\t(TAB)和%0a\n(LF)。

 --color[=<when>] 

尊重--format选项中指定的任何颜色。 &lt;when&gt;字段必须是alwaysneverauto之一(如果&lt;when&gt;不存在,则表现得好像always一样)。

 --shell 
 --perl 
 --python 
 --tcl 

如果给定,则替换%(fieldname)占位符的字符串将被引用为适合指定宿主语言的字符串文字。这是为了生成一个可以直接“评估”的 scriptlet。

 --points-at=<object> 

仅列出指向给定对象的引用。

 --merged[=<object>] 

仅列出可从指定提交(HEAD,如果未指定)可访问的引用的 refs,与--no-merged不兼容。

 --no-merged[=<object>] 

仅列出其指针无法从指定的提交(如果未指定,则为 HEAD)可访问的 refs,与--merged不兼容。

 --contains[=<object>] 

仅列出包含指定提交的引用(如果未指定,则为 HEAD)。

 --no-contains[=<object>] 

仅列出不包含指定提交的引用(如果未指定,则为 HEAD)。

 --ignore-case 

排序和过滤 refs 不区分大小写。

字段名称

来自引用对象中的结构化字段的各种值可用于插入到结果输出中,或作为排序键。

对于所有对象,可以使用以下名称:

 refname 

ref 的名称($ GIT_DIR /之后的部分)。对于 ref 附加:short的非模糊短名称。选项 core.warnAmbiguousRefs 用于选择严格的缩写模式。如果附加lstrip=&lt;N&gt;rstrip=&lt;N&gt;),从参考号的前面(后面)剥离&lt;N&gt;斜线分离的路径分量(例如%(refname:lstrip=2)refs/tags/foo变为foo并且%(refname:rstrip=2)变为refs/tags/foo进入refs)。如果&lt;N&gt;为负数,则从指定端剥离尽可能多的路径组件以留下-&lt;N&gt;路径组件(例如%(refname:lstrip=-2)refs/tags/foo变为tags/foo%(refname:rstrip=-1)refs/tags/foo变为refs/tags/foo COD17])。当 ref 没有足够的组件时,如果使用正< N>进行剥离,则结果将变为空字符串,或者如果使用负< N>进行剥离,则结果将变为完整的 refname。两者都不是错误。

strip可以用作lstrip的同义词。

 objecttype 

对象的类型(blobtreecommittag)。

 objectsize 

对象的大小(与 git cat-file -s 报告相同)。附加:disk以获取对象占用磁盘的大小(以字节为单位)。请参阅下面CAVEATS部分中有关磁盘大小的说明。

 objectname 

对象名称(又名 SHA-1)。对于对象名称的非模糊缩写,附加:short。对于具有所需长度的对象名称的缩写,附加:short=&lt;length&gt;,其中最小长度为 MINIMUM_ABBREV。可能会超出长度以确保唯一的对象名称。

 deltabase 

如果将其存储为 delta,则会扩展为给定对象的 delta base 的对象名称。否则它会扩展为空对象名称(全为零)。

 upstream 

本地引用的名称,可以被视为显示引用的“上游”。以与上述refname相同的方式尊重:short:lstrip:rstrip。另外尊重:track以显示“[前 N,后 M]”和:trackshort以显示简洁版本:“>” (提前),“<” (后面),“<>” (前后)或“=”(同步)。每当遇到未知的上游引用时,:track也会打印“[gone]”。附加:track,nobracket以显示没有括号的跟踪信息(即“在 N 之前,在 M 之后”)。

对于任何远程跟踪分支%(upstream)%(upstream:remotename)%(upstream:remoteref)分别指代远程名称和被跟踪远程 ref 的名称。换句话说,远程跟踪分支可以通过使用 refspec %(upstream:remoteref):%(upstream)%(upstream:remotename)获取来显式和单独更新。

如果 ref 没有与之关联的跟踪信息,则无效。除nobracket之外的所有选项都是互斥的,但如果一起使用,则选择最后一个选项。

 push 

本地引用的名称,表示显示的引用的@{push}位置。与upstream一样,:short:lstrip:rstrip:track:trackshort:remotename:remoteref选项。如果未配置@{push} ref,则生成空字符串。

 HEAD 

* 如果 HEAD 匹配当前 ref(检出的分支),否则。

 color 

更改输出颜色。后跟:&lt;colorname&gt;,其中颜色名称在 git-config [1] 的“CONFIGURATION FILE”部分的值下描述。例如,%(color:bold red)

 align 

左,中,或右对齐%(对齐:...)和%(结束)之间的内容。 “对齐:”之后是以逗号分隔的任何顺序的width=&lt;width&gt;position=&lt;position&gt;,其中&lt;position&gt;是左,右或中间,默认为左,&lt;width&gt;是内容的总长度对齐。为简洁起见,可以省略“width =”和/或“position =”前缀,并且< width>和< position>用来代替。例如,%(align:&lt;width&gt;,&lt;position&gt;)。如果内容长度大于宽度,则不执行对齐。如果与--quote一起使用,则引用%(align:...)和%(end)之间的所有内容,但如果嵌套,则只有最顶层执行引用。

 if 

用作%(if)...%(然后)...%(结束)或%(如果)...%(然后)...%(否则)...%(结束)。如果在%(if)之后有一个带有值或字符串文字的原子,则打印%(then)之后的所有内容,否则如果使用%(else)原子,则打印%(else)之后的所有内容。我们在%(然后)之前评估字符串时忽略空格,当我们使用打印“*”或“”的%(HEAD)原子并且我们想要仅在条件下应用 _ 时这很有用 HEAD 参考。附加“:equals =< string>”或“:notequals =< string>”比较%(if:...)和%(then)原子与给定字符串之间的值。_

 symref 

给定符号 ref 引用的引用。如果不是符号引用,则不打印任何内容。以与refname相同的方式尊重:short:lstrip:rstrip选项。

除上述内容外,对于提交和标记对象,标题字段名称(treeparentobjecttypetag)可用于指定标题字段中的值。

对于提交和标记对象,特殊的creatordatecreator字段将对应于committertagger字段中的相应日期或名称 - 电子邮件 - 日期元组,具体取决于对象类型。这些用于处理带注释和轻量级标签的混合。

将 name-email-date 元组作为其值(authorcommittertagger)的字段可以后缀nameemaildate以提取指定的组件。

提交和标记对象中的完整消息是contents。它的第一行是contents:subject,其中 subject 是提交消息的所有行的连接,直到第一个空行。下一行是contents:body,其中 body 是第一个空白行之后的所有行。可选的 GPG 签名是contents:signature。使用contents:lines=N获得消息的第一N行。另外,由 git-interpre-trailers [1] 解释的预告片作为trailers(或通过使用历史别名contents:trailers)获得。使用trailers:only可以省略拖车块中的非拖车线。可以从预告片中删除空格连续,以便每个预告片单独出现在一行上,其全部内容为trailers:unfold。两者可以一起用作trailers:unfold,only

出于排序目的,具有数值的字段按数字顺序排序(objectsizeauthordatecommitterdatecreatordatetaggerdate)。所有其他字段用于按字节值顺序排序。

还有一个按版本排序的选项,这可以通过使用 fieldname version:refname或其别名v:refname来完成。

在任何情况下,引用不适用于 ref 引用的对象的字段的字段名称不会导致错误。它返回一个空字符串。

作为日期类型字段的特殊情况,您可以通过添加:后跟日期格式名称来指定日期的格式(请参阅 git-rev-list [1]的--date选项的值需要)。

像%(对齐)和%(如果)这样的原子总是需要匹配的%(结束)。我们称它们为“开放原子”,有时将它们表示为%($ open)。

当特定于脚本语言的引用生效时,顶级开放原子与其匹配的%(结束)之间的所有内容都根据开放原子的语义进行评估,并且仅引用顶级开放原子的结果。

例子

直接生成格式化文本的示例。显示最近 3 个标记的提交:

#!/bin/sh

git for-each-ref --count=3 --sort='-*authordate' \
--format='From: %(*authorname) %(*authoremail)
Subject: %(*subject)
Date: %(*authordate)
Ref: %(*refname)

%(*body)
' 'refs/tags'

一个简单的例子,展示了在输出中使用 shell eval,演示了如何使用--shell。列出所有头的前缀:

#!/bin/sh

git for-each-ref --shell --format="ref=%(refname)" refs/heads | \
while read entry
do
	eval "$entry"
	echo `dirname $ref`
done

关于标签的更详细的报告,证明格式可能是整个脚本:

#!/bin/sh

fmt='
	r=%(refname)
	t=%(*objecttype)
	T=${r#refs/tags/}

	o=%(*objectname)
	n=%(*authorname)
	e=%(*authoremail)
	s=%(*subject)
	d=%(*authordate)
	b=%(*body)

	kind=Tag
	if test "z$t" = z
	then
		# could be a lightweight tag
		t=%(objecttype)
		kind="Lightweight tag"
		o=%(objectname)
		n=%(authorname)
		e=%(authoremail)
		s=%(subject)
		d=%(authordate)
		b=%(body)
	fi
	echo "$kind $T points at a $t object $o"
	if test "z$t" = zcommit
	then
		echo "The commit was authored by $n $e
at $d, and titled

    $s

Its message reads as:
"
		echo "$b" | sed -e "s/^/    /"
		echo
	fi
'

eval=`git for-each-ref --shell --format="$fmt" \
	--sort='*objecttype' \
	--sort=-taggerdate \
	refs/tags`
eval "$eval"

显示%(if)...%(然后)...%(else)...%(end)的用法的示例。这为当前分支添加星号前缀。

git for-each-ref --format="%(if)%(HEAD)%(then)* %(else)  %(end)%(refname:short)" refs/heads/

显示%(if)...%(然后)...%(结束)的用法的示例。这将打印 authorname(如果存在)。

git for-each-ref --format="%(refname)%(if)%(authorname)%(then) Authored by: %(authorname)%(end)"

CAVEATS

请注意,磁盘上对象的大小是准确报告的,但应该注意得出哪些引用或对象负责磁盘使用的结论。打包的非 delta 对象的大小可能远大于对其增量的对象的大小,但是选择哪个对象是基础并且 delta 是任意的并且在重新打包期间可能会发生变化。

还要注意,对象的多个副本可能存在于对象数据库中;在这种情况下,未定义将报告哪个副本的大小或增量基数。

也可以看看

git-show-ref [1]

GIT

部分 git [1] 套件

git-hash-object

原文: git-scm.com/docs/git-hash-object

名称

git-hash-object - 计算对象 ID,并可选择从文件创建 blob

概要

git hash-object [-t <type>] [-w] [--path=<file>|--no-filters] [--stdin [--literally]] [--] <file>…​
git hash-object [-t <type>] [-w] --stdin-paths [--no-filters]

描述

使用指定文件的内容(可以在工作树之外)计算具有指定类型的对象的对象 ID 值,并可选择将结果对象写入对象数据库。将其对象 ID 报告给其标准输出。 git cvsimport 使用它来更新索引而不修改工作树中的文件。当< type>未指定,默认为“blob”。

OPTIONS

 -t <type> 

指定类型(默认值:“blob”)。

 -w 

实际上将对象写入对象数据库。

 --stdin 

从标准输入而不是从文件中读取对象。

 --stdin-paths 

从标准输入读取文件名,每行一个,而不是从命令行读取。

 --path 

哈希对象,因为它位于给定的路径。文件的位置不会直接影响哈希值,但路径用于确定在将对象放置到对象数据库之前应该将哪些 Git 过滤器应用于对象,并且,作为应用过滤器的结果,实际的 blob 放置进入对象数据库可能与给定文件不同。此选项主要用于散列位于工作目录外部的临时文件或从 stdin 读取的文件。

 --no-filters 

按原样哈希内容,忽略属性机制选择的任何输入过滤器,包括行尾转换。如果从标准输入读取文件,则始终隐含,除非给出--path选项。

 --literally 

允许--stdin将任何垃圾散列到松散的对象中,否则可能无法通过标准对象解析或 git-fsck 检查。用于压力测试 Git 本身或复制野外遇到的腐败或伪造物体的特征。

GIT

部分 git [1] 套件

git-ls-files

原文: git-scm.com/docs/git-ls-files

名称

git-ls-files - 显示索引和工作树中的文件信息

概要

git ls-files [-z] [-t] [-v] [-f]
		(--[cached|deleted|others|ignored|stage|unmerged|killed|modified])*
		(-[c|d|o|i|s|u|k|m])*
		[--eol]
		[-x <pattern>|--exclude=<pattern>]
		[-X <file>|--exclude-from=<file>]
		[--exclude-per-directory=<file>]
		[--exclude-standard]
		[--error-unmatch] [--with-tree=<tree-ish>]
		[--full-name] [--recurse-submodules]
		[--abbrev] [--] [<file>…​]

描述

这将目录高速缓存索引中的文件列表与实际工作目录列表合并,并显示两者的不同组合。

以下一个或多个选项可用于确定显示的文件:

OPTIONS

 -c 
 --cached 

在输出中显示缓存的文件(默认)

 -d 
 --deleted 

在输出中显示已删除的文件

 -m 
 --modified 

在输出中显示已修改的文件

 -o 
 --others 

在输出中显示其他(即未跟踪)文件

 -i 
 --ignored 

仅显示输出中的忽略文件。在索引中显示文件时,仅打印与排除模式匹配的文件。显示“其他”文件时,仅显示与排除模式匹配的文件。标准忽略规则不会自动激活,因此至少需要一个--exclude*选项。

 -s 
 --stage 

在输出中显示暂存内容的模式位,对象名称和阶段编号。

 --directory 

如果整个目录被归类为“其他”,则只显示其名称(带斜杠)而不是其全部内容。

 --no-empty-directory 

不要列出空目录。没有--directory 没有效果。

 -u 
 --unmerged 

在输出中显示未合并的文件(强制 - 阶段)

 -k 
 --killed 

显示文件系统上由于文件/目录冲突而需要删除的文件,以使 checkout-index 成功。

 -z 

\ 0 输出行终止,不引用文件名。有关详细信息,请参阅下面的 OUTPUT。

 -x <pattern> 
 --exclude=<pattern> 

跳过与图案匹配的未跟踪文件。请注意,pattern 是 shell 通配符模式。有关详细信息,请参阅下面的 EXCLUDE PATTERNS。

 -X <file> 
 --exclude-from=<file> 

从< file>中读取排除模式;每行 1 个。

 --exclude-per-directory=<file> 

阅读仅适用于< file>中的目录及其子目录的其他排除模式。

 --exclude-standard 

添加标准 Git 排除项:.git / info / exclude,.gitignore 在每个目录中,以及用户的全局排除文件。

 --error-unmatch 

如果有任何< file>没有出现在索引中,将其视为错误(返回 1)。

 --with-tree=<tree-ish> 

使用--error-unmatch 扩展用户提供的< file>时(即路径模式)路径的参数,假装自从命名的< tree-ish>以来在索引中删除的路径。仍然存在。将此选项与-s-u选项一起使用没有任何意义。

 -t 

此功能已被半弃用。出于脚本目的, git-status [1] --porcelaingit-diff-files [1] --name-status几乎总是优秀的替代品,用户应该看一下 git-status [1] --shortgit-diff [1] --name-status,用于更加用户友好的替代品。

此选项在每行的开头标识具有以下标记(后跟空格)的文件状态:

 H 

缓存

 S 

跳 worktree

 M 

未合并

 R 

删除/删除

 C 

改性的/改变

 K 

被杀

 ? 

其他

 -v 

-t类似,但对于标记为 _ 的文件使用小写字母假设不变 _(参见 git-update-index [1] )。

 -f 

-t类似,但对于标记为 _fsmonitor 有效 _ 的文件使用小写字母(参见 git-update-index [1] )。

 --full-name 

从子目录运行时,该命令通常输出相对于当前目录的路径。此选项强制路径相对于项目顶级目录输出。

 --recurse-submodules 

递归调用存储库中每个子模块上的 ls-files。目前只支持--cached 模式。

 --abbrev[=<n>] 

不显示完整的 40 字节十六进制对象行,而是仅显示部分前缀。可以使用--abbrev =< n>指定非默认位数。

 --debug 

在描述文件的每一行之后,添加有关其缓存条目的更多数据。这旨在显示尽可能多的手动检查信息;确切的格式可能随时改变。

 --eol 

显示< eolinfo>和< eolattr>的文件。 < eolinfo>是当“text”属性为“auto”(或未设置且 core.autocrlf 不为 false)时 Git 使用的文件内容标识。 < eolinfo>是“-text”,“none”,“lf”,“crlf”,“mixed”或“”。

“”表示该文件不是常规文件,它不在索引中或在工作树中不可访问。

< eolattr>是签出或提交时使用的属性,它是“”,“ - text”,“text”,“text = auto”,“text eol = lf”,“text eol = crlf”。由于支持 Git 2.10“text = auto eol = lf”和“text = auto eol = crlf”。

< eolinfo>都是在索引(“i /< eolinfo>”)和工作树(“w /< eolinfo>”)中显示常规文件,然后是(“attr /< eolattr>”)。

 -- 

不要将任何更多的参数解释为选项。

 <file> 

要显示的文件。如果没有给出文件,则显示与其他指定条件匹配的所有文件。

OUTPUT

git ls-files 只输出文件名,除非指定了--stage,在这种情况下输出:

[<tag> ]<mode> <object> <stage> <file>

git ls-files --ee 将显示 i /< eolinfo>< SPACES> w /< eolinfo>< SPACES> attr /< eolattr>< SPACE *>< TAB> ;<文件>

git ls-files --unmergedgit ls-files --stage 可用于检查未合并路径的详细信息。

对于未合并的路径,索引不是记录单个模式/ SHA-1 对,而是记录最多三个这样的对;一个来自阶段 1 中的树 O,阶段 2 中的 A 和阶段 3 中的 B.一个用户(或瓷器)可以使用该信息来查看最终应该在路径上记录的内容。 (有关状态的更多信息,请参见 git-read-tree [1]

如果没有-z选项,则会引用具有“异常”字符的路径名,如配置变量core.quotePath所述(参见 git-config [1] )。使用-z,文件名逐字输出,行以 NUL 字节终止。

排除模式

git ls-files 可以在遍历目录树时使用“排除模式”列表,并查找文件以显示指定标志 - 其他或--ignored 的时间。 gitignore [5] 指定排除模式的格式。

这些排除模式来自这些地方,依次为:

  1. 命令行标志--exclude =< pattern>指定单个模式。模式的排序顺序与它们在命令行中出现的顺序相同。

  2. 命令行标志--exclude-from =< file>指定包含模式列表的文件。模式的排序顺序与文件中出现的顺序相同。

  3. 命令行标志--exclude-per-directory =< name>指定每个目录 git ls-files 检查的文件名,通常是.gitignore。更深层目录中的文件优先。模式的排序顺序与文件中出现的顺序相同。

在命令行中使用--exclude 或从--exclude-from 指定的文件读取的模式相对于目录树的顶部。从--exclude-per-directory 指定的文件读取的模式是相对于模式文件出现的目录。

也可以看看

git-read-tree [1]gitignore [5]

GIT

部分 git [1] 套件

git-merge-base

原文: git-scm.com/docs/git-merge-base

名称

git-merge-base - 为合并找到尽可能好的共同祖先

概要

git merge-base [-a|--all] <commit> <commit>…​
git merge-base [-a|--all] --octopus <commit>…​
git merge-base --is-ancestor <commit> <commit>
git merge-base --independent <commit>…​
git merge-base --fork-point <ref> [<commit>]

描述

git merge-base 找到两个提交之间最好的共同祖先,用于三向合并。如果后者是前者的祖先,一个共同的祖先 _ 比另一个共同的祖先更好 _。没有任何更好的共同祖先的共同祖先是 _ 最佳共同祖先 _,即 _ 合并基 _。请注意,一对提交可以有多个合并基础。

操作模式

作为最常见的特殊情况,在命令行上仅指定两个提交意味着计算给定两个提交之间的合并基础。

更一般地,在计算合并基数的两个提交中,一个由命令行上的第一个提交参数指定;另一个提交是(可能是假设的)提交,它是命令行上所有剩余提交的合并。

因此,如果指定了两个以上的提交,则 _ 合并库 _ 不一定包含在每个提交参数中。当与--merge-base选项一起使用时,这与 git-show-branch [1] 不同。

 --octopus 

计算所有提供的提交的最佳共同祖先,为 n 路合并做准备。这模仿了 git show-branch --merge-base 的行为。

 --independent 

不是打印合并库,而是使用相同的祖先打印提供的提交的最小子集。换句话说,在给出的提交中,列出那些不能从任何其他提交的提交。这模仿了 git show-branch --independent 的行为。

 --is-ancestor 

检查第一个< commit>是第二个< commit>的祖先,如果为 true 则退出,状态为 0,否则退出状态为 1。错误由非零状态发出信号,该状态不为 1。

 --fork-point 

找到分支(或任何导致< commit>的历史记录)从另一个分支(或任何引用)< ref>分叉的点。这不只是寻找两个提交的共同祖先,而且还考虑了< ref>的 reflog。查看导致< commit>的历史记录分支早期的分支< ref>分叉(见下面关于这种模式的讨论)。

OPTIONS

 -a 
 --all 

输出提交的所有合并基础,而不是仅输出一个。

讨论

给定两个提交 ABgit merge-base A B将通过父关系输出可从 AB 到达的提交。

例如,使用此拓扑:

         o---o---o---B
        /
---o---1---o---o---o---A

AB 之间的合并碱基是 1

给定三次提交 ABCgit merge-base A B C将计算 A 和假设提交 _ 之间的合并基数 M_ ,是 BC 之间的合并。例如,使用此拓扑:

       o---o---o---o---C
      /
     /   o---o---o---B
    /   /
---2---1---o---o---o---A

git merge-base A B C的结果是 1 。这是因为 BC 之间具有合并提交 M 的等效拓扑是:

       o---o---o---o---o
      /                 \
     /   o---o---o---o---M
    /   /
---2---1---o---o---o---A

git merge-base A M的结果是 1 。提交 2 也是 AM 之间的共同祖先,但 1 是更好的共同祖先,因为 21 的祖先。因此, 2 不是合并基础。

git merge-base --octopus A B C的结果是 2 ,因为 2 是所有提交的最佳共同祖先。

当历史涉及纵横交错时,两个提交可以有不止一个 _ 最佳 _ 共同祖先。例如,使用此拓扑:

---1---o---A
    \ /
     X
    / \
---2---o---o---B

12 都是 A 和 B 的合并碱基。两者都不比另一个好(两者都是 _ 最佳 _ 合并碱基)。如果未给出--all选项,则未指定输出哪一个最佳选项。

在两个提交 A 和 B 之间检查“快进”的常用习惯用法是(或者至少用于)计算 A 和 B 之间的合并基础,并检查它是否与 A 相同,在这种情况下,A 是 B 的祖先。你会看到这个习惯用法经常用在较旧的脚本中。

A=$(git rev-parse --verify A)
if test "$A" = "$(git merge-base A B)"
then
	... A is an ancestor of B ...
fi

在现代 git 中,您可以更直接地说出这一点:

if git merge-base --is-ancestor A B
then
	... A is an ancestor of B ...
fi

代替。

关于叉点模式的讨论

处理使用git checkout -b topic origin/master创建的topic分支后,远程跟踪分支origin/master的历史记录可能已经倒回并重建,从而导致此形状的历史记录:

                 o---B2
                /
---o---o---B1--o---o---o---B (origin/master)
        \
         B0
          \
           D0---D1---D (topic)

其中origin/master用于指向提交 B0,B1,B2,现在它指向 B,当origin/master位于 B0 时,您的topic分支在它上面启动,并且您构建了三个提交,D0, D1 和 D,在它上面。想象一下,您现在想要在更新的 origin / master 之上重新设置您在该主题上所做的工作。

在这种情况下,git merge-base origin/master topic将在上图中返回 B0 的父节点,但是 B0 ^ .. D 是而不是你想要在 B 之上重放的提交范围(它包括 B0) ,这不是你写的;它是一个提交,当它从 B0 移动到 B1 时,另一方丢弃了)。

git merge-base --fork-point origin/master topic旨在帮助解决此类问题。它不仅需要 B,还需要 B0,B1 和 B2(即存储库的 reflog 知道的远程跟踪分支的旧技巧),以查看构建主题分支的提交并找到 B0,允许您仅重放对你主题的提交,不包括后来丢弃的提交。

于是

$ fork_point=$(git merge-base --fork-point origin/master topic)

会找到 B0,和

$ git rebase --onto origin/master $fork_point topic

将重放 B 顶部的 D0,D1 和 D 以创建此形状的新历史记录:

		 o---B2
		/
---o---o---B1--o---o---o---B (origin/master)
	\                   \
	 B0                  D0'--D1'--D' (topic - updated)
	  \
	   D0---D1---D (topic - old)

需要注意的是,您的存储库中较旧的 reflog 条目可能会被git gc过期。如果远程跟踪分支origin/master的 reflog 中不再出现 B0,则--fork-point模式显然无法找到并失败,从而避免给出随机且无用的结果(例如 B0 的父级,就像同一命令一样没有--fork-point选项给出)。

此外,您使用--fork-point模式的远程跟踪分支必须是您的主题从其提示分叉的主题。如果你从一个比提示更早的提交分叉,这个模式将找不到叉点(想象在上面的示例历史 B0 不存在,origin / master 从 B1 开始,移到 B2 然后 B,你分叉你的主题 at origin / master ^当 origin / master 为 B1 时;历史的形状与上面相同,没有 B0,B1 的父级是git merge-base origin/master topic正确找到的,但--fork-point模式不会,因为它不是曾经位于 origin / master 的提交之一。

也可以看看

git-rev-list [1]git-show-branch [1]git-merge [1]

GIT

部分 git [1] 套件

git-read-tree

原文: git-scm.com/docs/git-read-tree

名称

git-read-tree - 将树信息读入索引

概要

git read-tree [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>]
		[-u [--exclude-per-directory=<gitignore>] | -i]]
		[--index-output=<file>] [--no-sparse-checkout]
		(--empty | <tree-ish1> [<tree-ish2> [<tree-ish3>]])

描述

读取由< tree-ish>给出的树信息。进入索引,但实际上并没有更新它“缓存”的任何文件。 (参见: git-checkout-index [1]

可选地,它可以将树合并到索引中,使用-m标志执行快进(即 2 路)合并或 3 路合并。与-m一起使用时,-u标志会使它还使用合并结果更新工作树中的文件。

普通合并由 git read-tree 本身完成。当 git read-tree 返回时,只有冲突路径处于未合并状态。

OPTIONS

 -m 

执行合并,而不仅仅是读取。如果您的索引文件包含未合并的条目,则该命令将拒绝运行,表示您尚未完成之前的合并。

 --reset 

与-m 相同,除了丢弃未合并的条目而不是失败。

 -u 

成功合并后,使用合并结果更新工作树中的文件。

 -i 

通常,合并需要索引文件以及工作树中的文件与当前头部提交保持同步,以免丢失本地更改。此标志禁用对工作树的检查,并且在创建与当前工作树状态不直接相关的树的合并到临时索引文件时使用。

 -n 
 --dry-run 

检查命令是否会出错,而不更新索引或工作树中的文件是否真实。

 -v 

显示检出文件的进度。

 --trivial 

限制 git read-tree 的三向合并只有在不需要文件级合并时才会发生,而不是为简单的情况解析合并并在索引中保留未解决的冲突文件。

 --aggressive 

通常, git read-tree 的三向合并解决了真正琐碎案例的合并,并使索引中的其他案例无法解决,因此瓷器可以实现不同的合并策略。此标志使命令在内部解决了几个案例:

  • 当一侧移除路径而另一侧离开路径未经修改时。决议是删除该路径。

  • 当双方都删除一条路径。决议是删除该路径。

  • 当双方都添加相同的路径时。决议是添加该路径。

 --prefix=<prefix> 

保留当前索引内容,并在&lt;prefix&gt;目录下读取指定 tree-ish 的内容。该命令将拒绝覆盖原始索引文件中已存在的条目。

 --exclude-per-directory=<gitignore> 

使用-u-m选项运行命令时,合并结果可能需要覆盖当前分支中未跟踪的路径。该命令通常拒绝继续合并以避免丢失这样的路径。然而,这种安全阀有时会妨碍。例如,经常会发生另一个分支添加了一个文件,该文件曾经是分支中生成的文件,当您在运行make之后但在运行make clean之前尝试切换到该分支时,安全阀会触发删除生成的文件。此选项告诉命令读取每个目录的排除文件(通常是 .gitignore ),并允许覆盖这样一个未跟踪但明确忽略的文件。

 --index-output=<file> 

而不是将结果写入$GIT_INDEX_FILE,而是在命名文件中写入结果索引。在命令运行时,原始索引文件使用与通常相同的机制锁定。该文件必须允许从通常索引文件旁边创建的临时文件重命名(2);通常这意味着它需要与索引文件本身位于同一文件系统上,并且您需要对索引文件和索引输出文件所在目录的写入权限。

 --[no-]recurse-submodules 

使用--recurse-submodules 将通过递归调用 read-tree,根据超级项目中记录的提交更新所有初始化子模块的内容,同时将子模块 HEAD 设置为在该提交时分离。

 --no-sparse-checkout 

即使core.sparseCheckout为 true,也禁用稀疏检出支持。

 --empty 

而不是将树对象读入索引,只需清空它。

 <tree-ish#> 

要读取/合并的树对象的 id。

并构

如果指定了-mgit read-tree 可以执行 3 种合并,如果只给出 1 棵树,则单个树合并,2 棵树的快进合并或 3 路合并如果提供 3 棵或更多树。

单树合并

如果仅指定了 1 个树,则 git read-tree 的操作就好像用户没有指定-m,除非原始索引具有给定路径名的条目,并且路径的内容匹配在读取树时,使用索引中的统计信息。 (换句话说,索引的 stat()s 优先于合并的树)。

这意味着如果你执行git read-tree -m &lt;newtree&gt;后跟git checkout-index -f -u -agit checkout-index 只检查真正改变的东西。

git diff-filesgit read-tree 之后运行时,这用于避免不必要的错误命中。

两棵树合并

通常,这被调用为git read-tree -m $H $M,其中$ H 是当前存储库的头部提交,而$ M 是外部树的头部,它只是在$ H 之前(即我们处于快速前进状态) )。

当指定了两个树时,用户告诉 git read-tree 如下:

  1. 当前索引和工作树是从$ H 派生的,但是用户可能会因为$ H 而对其进行局部更改。

  2. 用户希望快进到$ M。

在这种情况下,git read-tree -m $H $M命令确保没有因“合并”而丢失本地更改。以下是“结转”规则,其中“I”表示索引,“clean”表示索引和工作树重合,“exists”/“nothing”表示指定提交中存在路径:

	I                   H        M        Result
       -------------------------------------------------------
     0  nothing             nothing  nothing  (does not happen)
     1  nothing             nothing  exists   use M
     2  nothing             exists   nothing  remove path from index
     3  nothing             exists   exists,  use M if "initial checkout",
				     H == M   keep index otherwise
				     exists,  fail
				     H != M

        clean I==H  I==M
       ------------------
     4  yes   N/A   N/A     nothing  nothing  keep index
     5  no    N/A   N/A     nothing  nothing  keep index

     6  yes   N/A   yes     nothing  exists   keep index
     7  no    N/A   yes     nothing  exists   keep index
     8  yes   N/A   no      nothing  exists   fail
     9  no    N/A   no      nothing  exists   fail

     10 yes   yes   N/A     exists   nothing  remove path from index
     11 no    yes   N/A     exists   nothing  fail
     12 yes   no    N/A     exists   nothing  fail
     13 no    no    N/A     exists   nothing  fail

	clean (H==M)
       ------
     14 yes                 exists   exists   keep index
     15 no                  exists   exists   keep index

        clean I==H  I==M (H!=M)
       ------------------
     16 yes   no    no      exists   exists   fail
     17 no    no    no      exists   exists   fail
     18 yes   no    yes     exists   exists   keep index
     19 no    no    yes     exists   exists   keep index
     20 yes   yes   no      exists   exists   use M
     21 no    yes   no      exists   exists   fail

在所有“保留索引”的情况下,索引条目保持原始索引文件中的状态。如果条目不是最新的, git read-tree 在-u 标志下操作时保持工作树中的副本不变。

git read-tree 的这种形式成功返回时,您可以通过运行git diff-index --cached $M来查看您所做的哪些“本地更改”。请注意,这不一定与git diff-index --cached $H在这样的两个树合并之前产生的内容相匹配。这是因为案例 18 和 19 ---如果你已经有$ M 的变化(例如,你可能通过电子邮件以补丁形式提取),git diff-index --cached $H会告诉你这个合并之前的变化,但在两树合并后它不会显示在git diff-index --cached $M输出中。

案例 3 有点棘手,需要解释。逻辑上,此规则的结果应该是在用户暂停路径删除然后切换到新分支时删除路径。然而,这将阻止初始检出发生,因此仅当索引的内容为空时才修改规则以使用 M(新树)。否则,只要$ H 和$ M 相同,就会保留路径的删除。

三向合并

每个“索引”条目都有两位“阶段”状态。阶段 0 是正常阶段,并且是您在任何正常使用中看到的唯一一个。

但是,当你用三棵树做 git read-tree 时,“stage”从 1 开始。

这意味着你可以做到

$ git read-tree -m <tree1> <tree2> <tree3>

你将得到一个包含所有< tree1>的索引“stage1”中的条目,所有< tree2> “stage2”中的条目和所有< tree3> “stage3”中的条目。当执行将另一个分支合并到当前分支时,我们使用公共祖先树作为< tree1>,将当前分支头作为< tree2>,将另一个分支头作为< tree3>。

此外, git read-tree 具有特殊情况逻辑,表示:如果您在以下状态中看到一个在所有方面都匹配的文件,它会“折叠”回“stage0”:

  • 第 2 阶段和第 3 阶段是相同的;拿一个或另一个(没有区别 - 我们在第 2 阶段的分支机构和第 3 阶段的分支机构完成了相同的工作)

  • 阶段 1 和阶段 2 是相同的,阶段 3 是不同的;进入第 3 阶段(我们在第 2 阶段的分支从第 1 阶段的祖先开始没有做任何事情,而第 3 阶段的分支在第 3 阶段工作)

  • 阶段 1 和阶段 3 是相同的,阶段 2 是不同的阶段 2(我们做了什么,而他们什么也没做)

git write-tree 命令拒绝写一个无意义的树,如果它看到一个不是第 0 阶段的单个条目,它会抱怨未合并的条目。

好吧,这听起来像是一个完全荒谬的规则集合,但它实际上正是你想要的快速合并。不同的阶段代表“结果树”(阶段 0,又名“合并”),原始树(阶段 1,又名“orig”),以及您尝试合并的两棵树(分别为阶段 2 和阶段 3)。

当您启动与已填充的索引文件的 3 向合并时,阶段 1,2 和 3 的顺序(因此三个< tree-ish>命令行参数的顺序)非常重要。以下是该算法的工作原理:

  • 如果一个文件在所有三个树中以相同的格式存在,它将由 git read-tree 自动折叠为“合并”状态。

  • 具有 _ 任何 _ 差异的文件在三棵树中将永远保留为索引中的单独条目。决定如何删除非 0 阶段并插入合并版本取决于“瓷器策略”。

  • 索引文件使用所有这些信息保存和恢复,因此您可以逐步合并事物,但只要它具有阶段 1/2/3 中的条目(即“未合并条目”),您就无法写入结果。所以现在合并算法最终变得非常简单:

    • 按顺序遍历索引,并忽略阶段 0 的所有条目,因为它们已经完成。

    • 如果您找到“stage1”,但没有匹配的“stage2”或“stage3”,您知道它已从两个树中删除(它只存在于原始树中),并删除该条目。

    • 如果找到匹配的“stage2”和“stage3”树,则删除其中一个,然后将另一个转换为“stage0”条目。删除任何匹配的“stage1”条目(如果它也存在)。 ..所有正常的琐碎规则..

您通常会使用 git merge-index 与提供的 git merge-one-file 来完成最后一步。该脚本在合并每个路径和成功合并结束时更新工作树中的文件。

当您使用已填充的索引文件启动 3 向合并时,假定它表示工作树中文件的状态,甚至可以在索引文件中包含未记录更改的文件。进一步假设该状态是从阶段 2 树“导出”的。如果在原始索引文件中找到与第 2 阶段不匹配的条目,则 3 向合并将拒绝运行。

这样做是为了防止您丢失正在进行的工作更改,并在不相关的合并提交中混合您的随机更改。为了说明,假设您从最后提交到存储库的内容开始:

$ JC=`git rev-parse --verify "HEAD⁰"`
$ git checkout-index -f -u -a $JC

你做了随机编辑,没有运行 git update-index 。然后你注意到你的“上游”树的尖端已经提升,因为你从他身上拉了下来:

$ git fetch git://.... linus
$ LT=`git rev-parse FETCH_HEAD`

您的工作树仍然基于您的 HEAD($ JC),但您已经进行了一些编辑。三向合并确保你没有添加或修改索引条目,因为$ JC,如果你没有,那么做正确的事情。所以按以下顺序:

$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT
$ git merge-index git-merge-one-file -a
$ echo "Merge with Linus" | \
  git commit-tree `git write-tree` -p $JC -p $LT

您将提交的是$ JC 和$ LT 之间的纯合并,而不进行正在进行的工作更改,并且您的工作树将更新为合并的结果。

但是,如果工作树中的本地更改将被此合并覆盖, git read-tree 将拒绝运行以防止您的更改丢失。

换句话说,不必担心仅在工作树中存在的内容。如果项目的一部分中没有参与合并,则您的更改不会干扰合并,并且保持不变。当他们干扰时,合并甚至没有开始( git read-tree 大声抱怨并且在没有修改任何内容的情况下失败)。在这种情况下,您可以继续执行您正在执行的操作,并且当您的工作树已准备好(即您已完成正在进行的工作)时,再次尝试合并。

SPARSE CHECKOUT

“稀疏检出”允许稀疏地填充工作目录。它使用 skip-worktree 位(参见 git-update-index [1] )告诉 Git 工作目录中的文件是否值得查看。

git read-tree 和其他基于合并的命令( git mergegit checkout ...)可以帮助维护 skip-worktree 位图和工作目录更新。 $GIT_DIR/info/sparse-checkout用于定义跳过工作树参考位图。当 git read-tree 需要更新工作目录时,它会根据此文件重置索引中的 skip-worktree 位,该文件使用与.gitignore 文件相同的语法。如果条目与此文件中的模式匹配,则不会在该条目上设置 skip-worktree。否则,将设置 skip-worktree。

然后它将新的 skip-worktree 值与前一个值进行比较。如果 skip-worktree 从 set 变为 unset,它将添加相应的文件。如果它从未设置变为设置,则该文件将被删除。

虽然$GIT_DIR/info/sparse-checkout通常用于指定文件所在的文件,但您也可以使用否定模式指定 _ 而不是 _ 中的文件。例如,要删除文件unwanted

/*
!unwanted

另一个棘手的问题是,当您不再需要稀疏检出时,完全重新填充工作目录。您不能只禁用“稀疏检出”,因为 skip-worktree 位仍在索引中,并且您的工作目录仍然是稀疏填充的。您应该使用$GIT_DIR/info/sparse-checkout文件内容重新填充工作目录,如下所示:

/*

然后你可以禁用稀疏检出。默认情况下, git read-tree 和类似命令中的稀疏检出支持被禁用。您需要打开core.sparseCheckout才能获得稀疏的结帐支持。

也可以看看

git-write-tree [1] ; git-ls-files [1] ; gitignore [5]

GIT

部分 git [1] 套件

git-rev-list

原文: git-scm.com/docs/git-rev-list

名称

git-rev-list - 以反向时间顺序列出提交对象

概要

git rev-list [ --max-count=<number> ]
	     [ --skip=<number> ]
	     [ --max-age=<timestamp> ]
	     [ --min-age=<timestamp> ]
	     [ --sparse ]
	     [ --merges ]
	     [ --no-merges ]
	     [ --min-parents=<number> ]
	     [ --no-min-parents ]
	     [ --max-parents=<number> ]
	     [ --no-max-parents ]
	     [ --first-parent ]
	     [ --remove-empty ]
	     [ --full-history ]
	     [ --not ]
	     [ --all ]
	     [ --branches[=<pattern>] ]
	     [ --tags[=<pattern>] ]
	     [ --remotes[=<pattern>] ]
	     [ --glob=<glob-pattern> ]
	     [ --ignore-missing ]
	     [ --stdin ]
	     [ --quiet ]
	     [ --topo-order ]
	     [ --parents ]
	     [ --timestamp ]
	     [ --left-right ]
	     [ --left-only ]
	     [ --right-only ]
	     [ --cherry-mark ]
	     [ --cherry-pick ]
	     [ --encoding=<encoding> ]
	     [ --(author|committer|grep)=<pattern> ]
	     [ --regexp-ignore-case | -i ]
	     [ --extended-regexp | -E ]
	     [ --fixed-strings | -F ]
	     [ --date=<format>]
	     [ [ --objects | --objects-edge | --objects-edge-aggressive ]
	       [ --unpacked ]
	       [ --filter=<filter-spec> [ --filter-print-omitted ] ] ]
	     [ --missing=<missing-action> ]
	     [ --pretty | --header ]
	     [ --bisect ]
	     [ --bisect-vars ]
	     [ --bisect-all ]
	     [ --merge ]
	     [ --reverse ]
	     [ --walk-reflogs ]
	     [ --no-walk ] [ --do-walk ]
	     [ --count ]
	     [ --use-bitmap-index ]
	     <commit>…​ [ -- <paths>…​ ]

描述

列出通过遵循给定提交的parent链接可以访问的提交,但排除可以从它们前面的 ^ 给出的提交可以访问的提交。默认情况下,输出按反向时间顺序给出。

您可以将其视为一组操作。在命令行上给出的提交形成一组可从其中任何一个提交的提交,然后从该组中减去从前面的 ^ 给出的任何提交的提交。剩下的提交是命令输出中出现的。可以使用各种其他选项和路径参数来进一步限制结果。

因此,以下命令:

	$ git rev-list foo bar ^baz

表示“列出所有可从 foobar ,但不能从 baz ”访问的提交。

特殊符号“< commit1> .. < commit2> ”可用作“^'< commit1>'的缩写 < commit2> “。例如,以下任何一种都可以互换使用:

	$ git rev-list origin..HEAD
	$ git rev-list HEAD ^origin

另一个特殊符号是“< commit1> ... < commit2> ”,它对合并很有用。生成的提交集是两个操作数之间的对称差异。以下两个命令是等效的:

	$ git rev-list A B --not $(git merge-base --all A B)
	$ git rev-list A...B

rev-list 是一个非常重要的 Git 命令,因为它提供了构建和遍历提交祖先图的能力。出于这个原因,它有许多不同的选项,使它可以被命令使用,如 git bisectgit repack

OPTIONS

提交限制

除了使用说明书中解释的特殊符号指定应列出的提交范围之外,还可以应用其他提交限制。

除非另有说明,否则使用更多选项通常会进一步限制输出(例如,--since=&lt;date1&gt;限制提交比&lt;date1&gt;更新,并将其与--grep=&lt;pattern&gt;一起使用进一步限制其日志消息具有与&lt;pattern&gt;匹配的行的提交)。

请注意,这些是在提交排序和格式化选项之前应用的,例如--reverse

 -<number> 
 -n <number> 
 --max-count=<number> 

限制要输出的提交数量。

 --skip=<number> 

在开始显示提交输出之前,跳过 _ 编号 _ 提交。

 --since=<date> 
 --after=<date> 

显示比特定日期更新的提交。

 --until=<date> 
 --before=<date> 

显示超过特定日期的提交。

 --max-age=<timestamp> 
 --min-age=<timestamp> 

将提交输出限制为指定的时间范围。

 --author=<pattern> 
 --committer=<pattern> 

将提交输出限制为具有与指定模式(正则表达式)匹配的作者/提交者标题行的输出。对于多个--author=&lt;pattern&gt;,选择作者与任何给定模式匹配的提交(类似于多个--committer=&lt;pattern&gt;)。

 --grep-reflog=<pattern> 

将提交输出限制为具有与指定模式(正则表达式)匹配的 reflog 条目的输出。如果有多个--grep-reflog,则选择其 reflog 消息与任何给定模式匹配的提交。除非正在使用--walk-reflogs,否则使用此选项是错误的。

 --grep=<pattern> 

将提交输出限制为具有与指定模式(正则表达式)匹配的日志消息的输出。如果有多个--grep=&lt;pattern&gt;,则会选择其消息与任何给定模式匹配的提交(但请参见--all-match)。

 --all-match 

将提交输出限制为匹配所有给定--grep的输出,而不是匹配至少一个的输出。

 --invert-grep 

将提交输出限制为具有与--grep=&lt;pattern&gt;指定的模式不匹配的日志消息的输出。

 -i 
 --regexp-ignore-case 

匹配正则表达式限制模式而不考虑字母大小写。

 --basic-regexp 

将限制模式视为基本正则表达式;这是默认值。

 -E 
 --extended-regexp 

考虑限制模式是扩展正则表达式而不是默认的基本正则表达式。

 -F 
 --fixed-strings 

将限制模式视为固定字符串(不要将模式解释为正则表达式)。

 -P 
 --perl-regexp 

将限制模式视为与 Perl 兼容的正则表达式。

对这些类型的正则表达式的支持是可选的编译时依赖性。如果 Git 没有编译并支持它们,那么提供此选项将导致它死亡。

 --remove-empty 

当给定路径从树中消失时停止。

 --merges 

仅打印合并提交。这与--min-parents=2完全相同。

 --no-merges 

不要打印具有多个父级的提交。这与--max-parents=1完全相同。

 --min-parents=<number> 
 --max-parents=<number> 
 --no-min-parents 
 --no-max-parents 

仅显示至少(或最多)许多父提交的提交。特别是,--max-parents=1--no-merges相同,--min-parents=2--merges相同。 --max-parents=0给出所有 root 提交和--min-parents=3所有章鱼合并。

--no-min-parents--no-max-parents再次重置这些限制(无限制)。等效形式是--min-parents=0(任何提交具有 0 或更多父母)和--max-parents=-1(负数表示无上限)。

 --first-parent 

在看到合并提交时,仅遵循第一个父提交。在查看特定主题分支的演变时,此选项可以提供更好的概述,因为合并到主题分支往往只是关于不时调整到更新的上游,并且此选项允许您忽略引入的单个提交通过这样的合并你的历史。不能与--bisect 结合使用。

 --not 

反转所有后续修订说明符的 ^ 前缀(或缺少)的含义,直到下一个--not

 --all 

假设refs/中的所有引用与HEAD一起在命令行中列为 < commit>

 --branches[=<pattern>] 

假设refs/heads中的所有引用都在命令行中列为 < commit> 。如果 < pattern> 给出,将分支限制为匹配给定 shell glob 的分支。如果模式缺乏 _?最后暗示 _, *[/ *

 --tags[=<pattern>] 

假设refs/tags中的所有引用都在命令行中列为 < commit> 。如果 _< pattern>给出了 _,将标签限制为与给定 shell glob 匹配的标签。如果模式缺乏 _?最后暗示 _, *[/ *

 --remotes[=<pattern>] 

假设refs/remotes中的所有引用都在命令行中列为 < commit> 。如果 _< pattern>给出了 _,将远程跟踪分支限制为与给定 shell glob 匹配的分支。如果模式缺乏 _?最后暗示 _, *[/ *

 --glob=<glob-pattern> 

假设所有的 refs 匹配 shell glob < glob-pattern> 在命令行中列为 < commit> 。领先的 refs / 会在缺失时自动添加。如果模式缺乏 _?最后暗示 _, *[/ *

 --exclude=<glob-pattern> 

不包括引用匹配 < glob-pattern> 否则会考虑下一个--all--branches--tags--remotes--glob。重复此选项会累积排除模式,直至下一个--all--branches--tags--remotes--glob选项(其他选项或参数不会清除累积模式)。

当应用于--branches--tags--remotes时,给出的模式不应以refs/headsrefs/tagsrefs/remotes开始,并且当应用于--glob时,它们必须以refs/开头]或--all。如果打算使用尾随 / * ,则必须明确给出。

 --reflog 

假设 reflog 所提到的所有对象都在命令行中列为&lt;commit&gt;

 --single-worktree 

默认情况下,当有多个工作树时,将通过以下选项检查所有工作树(参见 git-worktree [1] ):--all--reflog--indexed-objects。此选项强制它们仅检查当前工作树。

 --ignore-missing 

在输入中看到无效的对象名称时,假装没有给出错误的输入。

 --stdin 

除了 _< commit>在命令行中列出 _,从标准输入中读取它们。如果看到--分隔符,请停止读取提交并开始读取路径以限制结果。

 --quiet 

不要将任何东西打印到标准输出。此表单主要用于允许调用者测试退出状态以查看一系列对象是否完全连接(或不完全连接)。它比将 stdout 重定向到/dev/null更快,因为输出不必格式化。

 --cherry-mark 

--cherry-pick(见下文)相同,但标记等效提交与=而不是省略它们,而与+不等价。

 --cherry-pick 

当提交集受限于对称差异时,省略任何引用与“另一方”上的另一个提交相同的更改的提交。

例如,如果您有两个分支,AB,通常只在一侧列出所有提交的方法是使用--left-right(请参阅下面--left-right选项说明中的示例) 。但是,它显示了从另一个分支中挑选出来的提交(例如,“b 上的第 3 个”可以从分支 A 中挑选出来)。使用此选项,将从输出中排除此类提交对。

 --left-only 
 --right-only 

列表仅在对称差异的相应侧提交,即仅在那些将被标记为&lt;的那些。 &gt; --left-right

例如,--cherry-pick --right-only A...B省略了来自B的提交,这些提交位于A中,或者补丁等效于A中的提交。换句话说,这列出了git cherry A B+提交。更确切地说,--cherry-pick --right-only --no-merges给出了确切的列表。

 --cherry 

--right-only --cherry-mark --no-merges的同义词;有用的是将输出限制在我们这一侧的提交中,并用git log --cherry upstream...mybranch标记已应用于分叉历史记录另一侧的输出,类似于git cherry upstream mybranch

 -g 
 --walk-reflogs 

而不是走提交祖先链,将 reflog 条目从最新的条目转到较旧的条目。使用此选项时,您无法指定要排除的提交(即 ^ commitcommit1..commit2commit1 ... commit2 表示法不能用过的)。

使用oneline以外的--pretty格式(出于显而易见的原因),这会导致输出从 reflog 中获取两行额外的信息。输出中的 reflog 指示符可能显示为ref@{Nth}(其中Nth是 reflog 中的反向时间顺序索引)或ref@{timestamp}(带有该条目的时间戳),具体取决于以下几条规则:

  1. 如果起始点指定为ref@{Nth},则显示索引格式。

  2. 如果起始点指定为ref@{now},则显示时间戳格式。

  3. 如果两者均未使用,但在命令行中给出了--date,则以--date请求的格式显示时间戳。

  4. 否则,显示索引格式。

--pretty=oneline下,提交消息在同一行上以此信息为前缀。此选项不能与--reverse组合使用。另见 git-reflog [1]

 --merge 

合并失败后,show refs 触摸有冲突的文件,并且在所有头上都不存在要合并的文件。

 --boundary 

输出排除边界提交。边界提交以-为前缀。

 --use-bitmap-index 

尝试使用 pack 位图索引(如果有的话)来加速遍历。请注意,当使用--objects遍历时,树和 blob 将不会打印其关联路径。

 --progress=<header> 

在考虑对象时显示 stderr 的进度报告。每次进度更新都会打印&lt;header&gt;文本。

历史简化

有时您只对历史记录的某些部分感兴趣,例如修改特定< path>的提交。但 _ 历史简化 _ 有两个部分,一部分是选择提交,另一部分是如何做,因为有各种策略来简化历史。

以下选项选择要显示的提交:

 <paths> 

提交修改给定的<路径>被选中。

 --simplify-by-decoration 

选择某些分支或标记引用的提交。

请注意,可以显示额外的提交以提供有意义的历史记录。

以下选项会影响简化的执行方式:

 Default mode 

将历史简化为最简单的历史,解释树的最终状态。最简单的,因为如果最终结果相同(即合并具有相同内容的分支),它会修剪一些侧分支

 --full-history 

与默认模式相同,但不修剪某些历史记录。

 --dense 

仅显示选定的提交,并显示一些具有有意义的历史记录。

 --sparse 

显示简化历史记录中的所有提交。

 --simplify-merges 

--full-history的附加选项,用于从生成的历史记录中删除一些不必要的合并,因为没有选定的提交有助于此合并。

 --ancestry-path 

当给出一系列要显示的提交时(例如 commit1..commit2commit2 ^ commit1 ),只显示直接存在于 commit1 之间的祖先链上的提交]和 commit2 ,即提交既是 commit1 的后代,又是 commit2 的祖先。

下面是更详细的解释。

假设您将foo指定为< paths>。我们将调用修改foo!TREESAME 的提交,以及其余的 TREESAME。 (在foo的差异滤波中,它们分别看起来不同且相等。)

在下文中,我们将始终参考相同的示例历史记录来说明简化设置之间的差异。我们假设您正在过滤此提交图中的文件foo

	  .-A---M---N---O---P---Q
	 /     /   /   /   /   /
	I     B   C   D   E   Y
	 \   /   /   /   /   /
	  `-------------'   X

历史 A --- Q 的水平线被视为每次合并的第一个父级。提交是:

  • I是初始提交,其中foo存在内容“asdf”,文件quux存在,内容为“quux”。初始提交与空树进行比较,因此I是!TREESAME。

  • A中,foo仅包含“foo”。

  • B包含与A相同的更改。它的合并M是微不足道的,因此对所有父母都是 TREESAME。

  • C不会更改foo,但是它的合并N会将其更改为“foobar”,因此它不是任何父级的 TREESAME。

  • Dfoo设置为“baz”。它的合并OND的字符串组合成“foobarbaz”;即,它不是任何父母的 TREESAME。

  • Equux更改为“xyzzy”,其合并P将字符串组合为“quux xyzzy”。 P是 TREESAME 到O,但不是E

  • X是一个独立的根提交,它添加了一个新文件sideY修改了它。 Y是 TREESAME 到X。它的合并Qside添加到PQ将 TREESAME 添加到P,但不添加到Y

rev-list根据是否使用--full-history和/或父改写(通过--parents--children)来回溯历史记录,包括或排除提交。可以使用以下设置。

 Default mode 

如果对任何父母不是 TREESAME,则包含提交(尽管可以更改,请参阅下面的--sparse)。如果提交是合并,并且它是一个父级的 TREESAME,则只关注该父级。 (即使有几个 TREESAME 父母,也只能跟随他们中的一个。)否则,请跟随所有父母。

这导致:

	  .-A---N---O
	 /     /   /
	I---------D

请注意,仅遵循 TREESAME 父级的规则(如果有的话)将完全从考虑中删除BC被认为是通过N,但是是 TREESAME。 Root 提交与空树进行比较,因此I是!TREESAME。

父/子关系仅在--parents中可见,但这不会影响在默认模式下选择的提交,因此我们显示了父行。

 --full-history without parent rewriting 

此模式与默认值在一点上不同:始终跟随合并的所有父项,即使它是其中一个的 TREESAME。即使合并的多个方面包含了包含的提交,这并不意味着合并本身就是!在这个例子中,我们得到了

	I  A  B  N  D  O  P  Q

M被排除在外,因为对父母双方都是 TREESAME。 ECB都走了,但只有B是!TREESAME,所以没有出现。

请注意,如果没有父改写,就不可能谈论提交之间的父/子关系,因此我们将它们显示为断开连接。

 --full-history with parent rewriting 

只有普通提交才包括在内!TREESAME(虽然可以更改,但请参见下面的--sparse)。

合并始终包括在内。但是,它们的父列表会被重写:沿着每个父项删除不包含在其中的提交。这导致了

	  .-A---M---N---O---P---Q
	 /     /   /   /   /
	I     B   /   D   /
	 \   /   /   /   /
	  `-------------'

--full-history比较而不重写上述内容。请注意,E被删除,因为它是 TREESAME,但是 P 的父列表被重写为包含E的父ICNXYQ也发生了同样的情况。

除上述设置外,您还可以更改 TREESAME 是否影响包含:

 --dense 

如果他们不是任何父母的 TREESAME,则包括走路的提交。

 --sparse 

包括所有步行的提交。

请注意,如果没有--full-history,这仍然可以简化合并:如果其中一个父项是 TREESAME,我们只遵循那个,所以合并的其他方面永远不会走。

 --simplify-merges 

首先,以与父改写的--full-history相同的方式构建历史图(参见上文)。

然后根据以下规则将每个提交C简化为最终历史记录中的替换C'

  • C'设置为C

  • C'的每个父P替换为其简化P'。在这个过程中,删除作为其他父母或祖先的祖先的父母将 TREESAME 提交到空树,并删除重复项,但要注意永远不要删除我们所有父母的 TREESAME。

  • 如果在此父级重写之后,C'是根或合并提交(具有零或> 1 父级),边界提交或!TREESAME,它仍然存在。否则,它将替换为其唯一的父级。

通过与--full-history与父重写进行比较,可以最好地显示出这种效果。这个例子变成了:

	  .-A---M---N---O
	 /     /       /
	I     B       D
	 \   /       /
	  `---------'

注意NPQ--full-history的主要差异:

  • N的父列表删除了I,因为它是另一个父M的祖先。仍然,N仍然是因为它是!TREESAME。

  • P的父列表同样删除了IP然后被完全删除,因为它有一个父母并且是 TREESAME。

  • Q的父列表将Y简化为X。然后删除X,因为它是 TREESAME 根。 Q然后被完全删除,因为它有一个父母并且是 TREESAME。

最后,还有第五种简化模式:

 --ancestry-path 

将显示的提交限制为直接在给定提交范围中的“from”和“to”提交之间的祖先链上的提交。即只显示“to”提交的祖先和“from”提交的后代的提交。

作为示例用例,请考虑以下提交历史记录:

	    D---E-------F
	   /     \       \
	  B---C---G---H---I---J
	 /                     \
	A-------K---------------L--M

常规 D..M 计算作为M的祖先的提交集,但不包括作为D的祖先的提交。这对于从D以来导致M的历史发生了什么是有用的,因为“D中没有M具有什么M”。这个例子中的结果将是所有提交,除了AB(当然还有D本身)。

当我们想知道M中的提交被D引入的 bug 污染并需要修复时,我们可能只想查看实际上 D..M 的子集D的后代,即排除CK。这正是--ancestry-path选项的作用。应用于 D..M 范围,它会导致:

		E-------F
		 \       \
		  G---H---I---J
			       \
				L--M

--simplify-by-decoration选项允许您通过省略未由标记引用的提交来仅查看历史拓扑的大图。如果(1)它们被标记引用,或(2)它们改变命令行上给出的路径的内容,则提交被标记为!TREESAME(换句话说,保持在上述历史简化规则之后)。所有其他提交都标记为 TREESAME(可以简化)。

Bisection Helpers

 --bisect 

将输出限制为一个提交对象,该提交对象大致位于包含和排除的提交之间。请注意,错误的二分法 ref refs/bisect/bad被添加到包含的提交(如果存在)中,并且良好的二分 refs refs/bisect/good-*被添加到被排除的提交(如果它们存在)。因此,假设refs/bisect/中没有引用,如果

	$ git rev-list --bisect foo ^bar ^baz

输出 _ 中点 _,两个命令的输出

	$ git rev-list foo ^midpoint
	$ git rev-list midpoint ^bar ^baz

将是大致相同的长度。因此,查找引入回归的更改将简化为二进制搜索:重复生成并测试新的“中点”,直到提交链长度为 1。不能与--first-parent 结合使用。

 --bisect-vars 

这计算与--bisect相同,只是不使用refs/bisect/中的 refs,除了输出准备好由 shell 评估的文本。这些行将中点修订的名称分配给变量bisect_rev,并将bisect_rev之后要测试的预期提交次数测试为bisect_nr,如果bisect_rev转动则预期要测试的提交次数如果bisect_rev证明对bisect_bad不好,那么预计要测试的提交数量,以及我们现在正在等待bisect_all的提交数量。

 --bisect-all 

这将输出包含和排除的提交之间的所有提交对象,按它们与包含和排除的提交的距离排序。不使用refs/bisect/中的参考号。首先显示最远离它们的距离。 (这是--bisect显示的唯一一个。)

这很有用,因为它可以很容易地选择一个好的提交来测试,当你想避免因某些原因测试它们时(例如它们可能无法编译)。

此选项可与--bisect-vars一起使用,在这种情况下,在所有已排序的提交对象之后,将存在与单独使用--bisect-vars时相同的文本。

提交订购

默认情况下,提交以反向时间顺序显示。

 --date-order 

在显示所有子项之前不显示父项,但在提交时间戳顺序中显示提交。

 --author-date-order 

在显示所有子项之前不显示父项,但在作者时间戳顺序中显示提交。

 --topo-order 

在显示所有子项之前不显示父项,并避免在多行历史记录中显示混合的提交。

例如,在这样的提交历史中:

    ---1----2----4----7
	\	       \
	 3----5----6----8---

其中数字表示提交时间戳的顺序,git rev-list--date-order的朋友按时间戳顺序显示提交:8 7 6 5 4 3 2 1。

使用--topo-order,他们将显示 8 6 5 3 7 4 2 1(或 8 7 4 2 6 5 3 1);为了避免将两个并行开发轨道的提交混合在一起,显示一些较旧的提交在较新的提交之前。

 --reverse 

输出要以相反顺序显示的提交(请参阅上面的“提交限制”部分)。不能与--walk-reflogs结合使用。

对象遍历

这些选项主要用于打包 Git 存储库。

 --objects 

打印列出的提交引用的任何对象的对象 ID。 --objects foo ^bar因此意味着“如果我有提交对象 bar 而不是 foo ”,则“发送我需要下载的所有对象 ID”。

 --in-commit-order 

按提交顺序打印树和 blob id。树和 blob id 在它们首次被提交引用后打印。

 --objects-edge 

--objects类似,但也打印带有“ - ”字符的排除提交的 ID。 git-pack-objects [1] 使用它来构建一个“瘦”包,它根据这些被排除的提交中包含的对象以分层的形式记录对象,以减少网络流量。

 --objects-edge-aggressive 

--objects-edge类似,但它更难以以增加时间为代价查找排除的提交。这用来代替--objects-edge为浅层存储库构建“瘦”包。

 --indexed-objects 

假装索引使用的所有树和 blob 都在命令行中列出。请注意,您可能也想使用--objects

 --unpacked 

仅适用于--objects;打印不在包中的对象 ID。

 --filter=<filter-spec> 

仅适用于--objects*之一;从打印对象列表中省略对象(通常是 blob)。 < filter-spec> 可能是以下之一:

形式 --filter = blob:none 省略所有 blob。

形式 --filter = blob:limit =< n> [kmg] 省略大于 n 个字节或单位的 blob。 n 可能为零。后缀 k,m 和 g 可用于命名 KiB,MiB 或 GiB 中的单位。例如, blob:limit = 1kblob 相同:limit = 1024

形式 --filter =稀疏:oid =< blob-ish> 使用包含在 blob(或 blob-expression)< blob-ish>中的稀疏检验规范。 省略在请求的 refs 上进行稀疏检出时不需要的 blob。

形式 --filter = sparse:path =< path> 类似地使用< path>中包含的稀疏检出规范。

形式 - 过滤器=树:<深度> 省略了从根树的深度> =< depth>的所有斑点和树木。 (如果对象位于所遍历的提交的多个深度处,则为最小深度)。 < depth> = 0 将不包含任何树或 blob,除非在命令行中显式包含(或使用--stdin 时的标准输入)。 < depth> = 1 将仅包括由< commit>可到达的提交直接引用的树和 blob。或明确给定的对象。 < depth> = 2 类似于< depth> = 1,同时还包括从明确给定的提交或树中移除一个级别的树和 blob。

 --no-filter 

关闭之前的--filter=参数。

 --filter-print-omitted 

仅适用于--filter=;打印过滤器省略的对象列表。对象 ID 以“〜”字符为前缀。

 --missing=<missing-action> 

一个调试选项,以帮助未来的“部分克隆”开发。此选项指定如何处理丢失的对象。

表格 --missing = error 请求如果遇到丢失的对象,则 rev-list 会停止并显示错误。这是默认操作。

如果遇到丢失的对象,表单 --missing = allow-any 将允许对象遍历继续。缺少的对象将默默地从结果中省略。

形式 --missing = allow-promisor 就像 _ 允许任何 _,但只允许对象遍历继续为 EXPECTED promisor 缺少对象。意外丢失的对象将引发错误。

表格 _- 丢失=打印 _ 就像 _ 允许任何 _,但也会打印缺失对象的列表。对象 ID 以“?”字符为前缀。

 --exclude-promisor-objects 

(仅供内部使用。)Prefilter 对象在 promisor 边界处遍历。这与部分克隆一起使用。这比--missing=allow-promisor更强,因为它限制了遍历,而不是仅仅消除有关丢失对象的错误。

 --no-walk[=(sorted|unsorted)] 

只显示给定的提交,但不要遍历他们的祖先。如果指定了范围,则无效。如果给出了参数unsorted,则提交将按命令行中给出的顺序显示。否则(如果sorted或没有给出参数),提交按提交时间以反向时间顺序显示。不能与--graph结合使用。

 --do-walk 

覆盖之前的--no-walk

提交格式

使用这些选项, git-rev-list [1] 的行为类似于更专业的提交日志工具系列: git-log [1]git-show [1]git-whatchanged [1]

 --pretty[=<format>] 
 --format=<format> 

以给定格式打印提交日志的内容,其中 < format> 可以是 oneline ,_ 短 培养基 更丰富 之一电子邮件 原始 格式:< string>_ 和 tformat:< string> 。当 < format> 不属于上述情况,并且其中包含 _%占位符 _,其行为就像 --pretty = tformat:< format> 给出了。

有关每种格式的一些其他详细信息,请参阅“PRETTY FORMATS”部分。当 =< format> 部分省略,默认为 medium

注意:您可以在存储库配置中指定默认的漂亮格式(请参阅 git-config [1] )。

 --abbrev-commit 

而不是显示完整的 40 字节十六进制提交对象名称,而只显示部分前缀。可以使用“--abbrev =< n>”指定非默认位数(如果显示,也会修改 diff 输出)。

对于使用 80 列终端的人来说,这应该使“--pretty = oneline”更具可读性。

 --no-abbrev-commit 

显示完整的 40 字节十六进制提交对象名称。这否定了--abbrev-commit以及暗示它的选项,例如“--oneline”。它还会覆盖log.abbrevCommit变量。

 --oneline 

这是一起使用的“--pretty = oneline --abbrev-commit”的简写。

 --encoding=<encoding> 

提交对象在其编码头中记录用于日志消息的编码;此选项可用于告诉命令以用户首选的编码重新编码提交日志消息。对于非管道命令,默认为 UTF-8。请注意,如果一个对象声称在X中编码并且我们在X中输出,我们将逐字输出该对象;这意味着原始提交中的无效序列可能会复制到输出中。

 --expand-tabs=<n> 
 --expand-tabs 
 --no-expand-tabs 

执行选项卡扩展(将每个选项卡替换为足够的空格以填充到日志消息中的 < n> 的倍数的下一个显示列),然后在输出中显示它。 --expand-tabs--expand-tabs=8的简写,--no-expand-tabs--expand-tabs=0的简写,它会禁用制表符扩展。

默认情况下,选项卡以相当格式展开,将日志消息缩进 4 个空格(即 medium ,默认情况下, fullfulller )。

 --show-signature 

通过将签名传递给gpg --verify并显示输出来检查已签名的提交对象的有效性。

 --relative-date 

--date=relative的同义词。

 --date=<format> 

仅对以人类可读格式显示的日期生效,例如使用--pretty时。 log.date config 变量为日志命令的--date选项设置默认值。默认情况下,日期显示在原始时区(提交者或作者)中。如果-local附加到格式(例如,iso-local),则使用用户的本地时区。

--date=relative显示相对于当前时间的日期,例如“2 小时前”。 -local选项对--date=relative无效。

--date=local--date=default-local的别名。

--date=iso(或--date=iso8601)以类似 ISO 8601 的格式显示时间戳。与严格的 ISO 8601 格式的区别在于:

  • 空格而不是T日期/时间分隔符

  • 时区和时区之间的空间

  • 时区的小时和分钟之间没有冒号

--date=iso-strict(或--date=iso8601-strict)以严格的 ISO 8601 格式显示时间戳。

  • --date=rfc(或--date=rfc2822)以 RFC 2822 格式显示时间戳,通常在电子邮件中找到。

  • --date=short仅以YYYY-MM-DD格式显示日期,但不显示时间。

  • --date=raw显示自纪元以来的秒数(1970-01-01 00:00:00 UTC),后跟一个空格,然后将时区显示为与 UTC 的偏移量(+-与四位数;前两位是小时,后两位是分钟)。即,好像时间戳是用strftime("%s %z")格式化的。请注意,-local选项不会影响秒 - 自 - 纪元值(始终以 UTC 为单位),但会切换附带的时区值。

  • --date=human如果时区与当前时区不匹配则显示时区,如果匹配则不显示整个日期(即跳过“今年”日期的打印年份,但也跳过整个日期如果它是在过去几天,我们可以说它是什么工作日)。对于较旧的日期,小时和分钟也被省略。

  • --date=unix将日期显示为 Unix 纪元时间戳(自 1970 年以来的秒数)。与--raw一样,它始终为 UTC,因此-local无效。

  • --date=format:...将格式...输入系统strftime,%z 和%Z 除外,它们在内部处理。使用--date=format:%c以系统区域设置的首选格式显示日期。有关格式占位符的完整列表,请参阅strftime手册。使用-local时,正确的语法是--date=format-local:...

  • --date=default是默认格式,类似于--date=rfc2822,但有一些例外:

  • 星期几之后没有逗号

  • 使用本地时区时,省略时区

 --header 

以 raw 格式打印提交的内容;每个记录用 NUL 字符分隔。

 --parents 

同时打印提交的父级(以“提交父级”的形式)。也可以启用父重写,请参阅上面的 _ 历史简化 _。

 --children 

同时打印提交的子项(以“提交子项...”的形式)。也可以启用父重写,请参阅上面的 _ 历史简化 _。

 --timestamp 

打印原始提交时间戳。

 --left-right 

标记可以从中获取提交的对称差异的哪一侧。左侧的提示以&lt;为前缀,右侧的提示以&gt;为前缀。如果与--boundary结合使用,则这些提交以-为前缀。

例如,如果您有此拓扑:

	     y---b---b  branch B
	    / \ /
	   /   .
	  /   / \
	 o---x---a---a  branch A

你会得到这样的输出:

	$ git rev-list --left-right --boundary --pretty=oneline A...B

	>bbbbbbb... 3rd on b
	>bbbbbbb... 2nd on b
	<aaaaaaa... 3rd on a
	<aaaaaaa... 2nd on a
	-yyyyyyy... 1st on b
	-xxxxxxx... 1st on a
 --graph 

在输出的左侧绘制提交历史的基于文本的图形表示。这可能会导致在提交之间打印额外的行,以便正确绘制图形历史记录。不能与--no-walk结合使用。

这使父进行重写,参见上面的 _ 历史简化 _。

默认情况下,这意味着--topo-order选项,但也可以指定--date-order选项。

 --show-linear-break[=<barrier>] 

当不使用--graph 时,所有历史分支都被展平,这使得很难看出两个连续的提交不属于线性分支。在这种情况下,此选项会在它们之间设置障碍。如果指定了&lt;barrier&gt;,则显示的是字符串而不是默认字符串。

 --count 

打印一个数字,说明将列出多少次提交,并禁止所有其他输出。与--left-right一起使用时,打印左右提交的计数,由制表符分隔。与--cherry-mark一起使用时,请忽略这些计数中的补丁等效提交,并打印由选项卡分隔的等效提交的计数。

漂亮的格式

如果提交是合并,并且如果漂亮格式不是 oneline ,_ 电子邮件 _ 或 raw ,则在 _ 作者之前插入另一行:_ 行。该行以“Merge:”开头,并且打印祖先提交的 sha1,用空格分隔。请注意,如果您限制了对历史记录的查看,则列出的提交可能不一定是直接父提交的列表:例如,如果您只对与某个目录或文件相关的更改感兴趣。

有几种内置格式,您可以通过设置漂亮的格式来定义其他格式。< name>将选项配置为另一种格式名称或 _ 格式:_ 字符串,如下所述(参见 git-config [1] )。以下是内置格式的详细信息:

  • oneline

    &lt;sha1&gt; &lt;title line&gt;
    

    这是为了尽可能紧凑。

  • _ 短 _

    commit &lt;sha1&gt;
    Author: &lt;author&gt;
    
    &lt;title line&gt;
    
  • _ 中 _

    commit &lt;sha1&gt;
    Author: &lt;author&gt;
    Date:   &lt;author date&gt;
    
    &lt;title line&gt;
    
    &lt;full commit message&gt;
    
  • _ 全 _

    commit &lt;sha1&gt;
    Author: &lt;author&gt;
    Commit: &lt;committer&gt;
    
    &lt;title line&gt;
    
    &lt;full commit message&gt;
    
  • _ 更丰富 _

    commit &lt;sha1&gt;
    Author:     &lt;author&gt;
    AuthorDate: &lt;author date&gt;
    Commit:     &lt;committer&gt;
    CommitDate: &lt;committer date&gt;
    
    &lt;title line&gt;
    
    &lt;full commit message&gt;
    
  • _ 电子邮件 _

    From &lt;sha1&gt; &lt;date&gt;
    From: &lt;author&gt;
    Date: &lt;author date&gt;
    Subject: [PATCH] &lt;title line&gt;
    
    &lt;full commit message&gt;
    
  • _ 原始 _

    raw 格式显示完整提交,与存储在提交对象中完全相同。值得注意的是,无论是否使用--abbrev 或--no-abbrev,SHA-1 都会完整显示,并且 _ 父 _ 信息显示真正的父提交,而不考虑移植或历史简化。请注意,此格式会影响提交的显示方式,但不会影响显示差异的方式,例如用git log --raw。要以原始 diff 格式获取完整对象名称,请使用--no-abbrev

  • _ 格式:< string>_

    _ 格式:< string>_ 格式允许您指定要显示的信息。它的工作方式有点像 printf 格式,但有一个值得注意的例外,即你用 %n 而不是 \ n 获得换行符。

    例如,_ 格式:“%h 的作者是%an,%ar%n 标题是>>%s<<%n”_ 将显示如下内容:

    The author of fe6e0ee was Junio C Hamano, 23 hours ago
    The title was &gt;&gt;t4119: test autocomputing -p&lt;n&gt; for traditional diff input.&lt;&lt;
    

    占位符是:

    • %H :提交哈希

    • %h :缩写提交哈希

    • %T :树形哈希

    • %t :缩写树哈希

    • %P :父哈希

    • %p :缩写为父哈希值

    • _%和 _:作者姓名

    • %aN :作者姓名(尊重.mailmap,见 git-shortlog [1]git-blame [1]

    • %ae :作者电邮

    • %aE :作者电子邮件(尊重.mailmap,见 git-shortlog [1]git-blame [1]

    • %ad :作者日期(格式尊重 - 日期=选项)

    • %aD :作者日期,RFC2822 风格

    • %ar :作者日期,相对

    • 的 _%:作者日期,UNIX 时间戳 _

    • %ai :作者日期,ISO 8601 样格式

    • %aI :作者日期,严格的 ISO 8601 格式

    • %cn :提交者名称

    • %cN :提交者名称(尊重.mailmap,见 git-shortlog [1]git-blame [1]

    • %ce :提交者电子邮件

    • %cE :提交者电子邮件(尊重.mailmap,参见 git-shortlog [1]git-blame [1]

    • %cd :提交者日期(格式尊重 - 日期=选项)

    • %cD :提交者日期,RFC2822 样式

    • %cr :提交者日期,相对

    • %ct :提交者日期,UNIX 时间戳

    • %ci :提交者日期,类似 ISO 8601 的格式

    • %cI :提交者日期,严格的 ISO 8601 格式

    • %d :引用名称,如 git-log [1] 的--decorate 选项

    • %D :没有“(”,“)”包装的引用名称。

    • %S :在达到提交的命令行上给出的引用名称(如git log --source),仅适用于git log

    • %e :编码

    • %s :受试者

    • %f :已清理的主题行,适用于文件名

    • %b :身体

    • %B :生体(未包裹的主体和身体)

    • %GG :来自 GPG 的签名提交的原始验证消息

    • %G? :显示好的(有效)签名“G”,坏签名显示“B”,有效期未知的好签名显示“U”,已过期的好签名显示“X”,“Y”代表由过期密钥签名的好签名,“R”表示由撤销密钥签名的好签名,“E”表示签名无法检查(例如缺少密钥),“N”表示没有签名

    • %GS :显示签名提交的签名者姓名

    • %GK :显示用于签署签名提交的密钥

    • %GF ​​:显示用于签署签名提交的密钥的指纹

    • %GP :显示主键的指纹,其子键用于签名提交的签名

    • %gD :reflog 选择器,例如refs/stash@{1}refs/stash@{2 minutes ago};格式遵循-g选项描述的规则。 @之前的部分是命令行中给出的 refname(因此git log -g refs/heads/master将产生refs/heads/master@{0})。

    • %gd :缩短了 reflog 选择器;与%gD相同,但 refname 部分缩短了人类的可读性(因此refs/heads/master变为master)。

    • %gn :reflog 身份名称

    • %gN :reflog 身份名称(尊重.mailmap,见 git-shortlog [1]git-blame [1]

    • %ge :reflog 身份电子邮件

    • %gE :reflog 身份邮件(尊重.mailmap,见 git-shortlog [1]git-blame [1]

    • %gs :reflog 主题

    • %Cred :将颜色切换为红色

    • %Cgreen :将颜色切换为绿色

    • %Cblue :将颜色切换为蓝色

    • %Creset :重置颜色

    • %C(...):颜色规格,如 git-config [1] 的“CONFIGURATION FILE”部分中的值所述。默认情况下,仅在启用日志输出时显示颜色(通过color.diffcolor.ui--color,并且如果我们要去终端,则尊重前者的auto设置)。 %C(auto,...)被接受为默认的历史同义词(例如,%C(auto,red))。即使没有启用颜色,指定%C(always,...)也会显示颜色(尽管只考虑使用--color=always为整个输出启用颜色,包括这种格式和其他任何 git 可能颜色的颜色)。单独auto(即%C(auto))将打开下一个占位符的自动着色,直到再次切换颜色。

    • %m :左(&lt;),右(&gt;)或边界(-)标记

    • %n :换行符

    • %% :原始

    • %x00 :从十六进制代码打印一个字节

    • %w([< w> [,< i1> [,< i2>]]]):切换行换行,类似 git-shortlog [1]的-w 选项

    • %<(< N> [,trunc | ltrunc | mtrunc]):使下一个占位符至少取 N 列,如果需要,在右边填充空格。如果输出长于 N 列,则可以选择在开头(ltrunc),中间(mtrunc)或结尾(trunc)截断。请注意,截断仅适用于 N> = 2。

    • %< |(< N>):使下一个占位符至少占用第 N 列,如果需要,在右边填充空格

    • %>(< N>)%> |(< N>):与 %相似,%< |(< N>)_,但左边的填充空格 _

    • %>(< N>)%> |(< N>):类似于 %>(< N>分别是 %> |(< N>),除非下一个占位符占用的空间多于给定的空间并且左侧有空格,请使用这些空格

    • %><(< N>)%>< |(< N>):类似于 %<(< N> )%< |(< N>),但填充两侧(即文本居中)

    • %(预告片[:options]):显示 git-interpret-trailers [1] 解释的正文预告片。 trailers字符串后面可以跟冒号和零个或多个逗号分隔选项。如果给出了only选项,则省略拖车块中的非拖车线。如果给出unfold选项,则表现得就像给出了 interpre-trailer 的--unfold选项一样。例如,%(trailers:only,unfold)两者都做。

| 注意 | 一些占位符可能依赖于修订遍历引擎的其他选项。例如,%g* reflog 选项将插入一个空字符串,除非我们遍历 reflog 条目(例如,通过git log -g)。如果命令行中尚未提供--decorate%d%D占位符将使用“短”装饰格式。 |

如果在占位符的 之后添加+(加号),则在扩展之前插入换行符当且仅当占位符扩展为非空字符串时。

如果在占位符的 之后添加-(减号),则当且仅当占位符扩展为空字符串时,才会删除紧接在扩展之前的所有连续换行符。

如果在占位符的 之后添加一个“空格”,则在扩展之前插入一个空格,当且仅当占位符扩展为非空字符串时。

  • tformat:

    _ 格式:_ 格式与 _ 格式完全相同:_,除了它提供“终结符”语义而不是“分隔符”语义。换句话说,每个提交都附加了消息终止符(通常是换行符),而不是在条目之间放置的分隔符。这意味着单行格式的最终​​输入将使用新行正确终止,就像“oneline”格式一样。例如:

    $ git log -2 --pretty=format:%h 4da45bef \
      | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
    4da45be
    7134973 -- NO NEWLINE
    
    $ git log -2 --pretty=tformat:%h 4da45bef \
      | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
    4da45be
    7134973
    

    此外,其中包含%的任何无法识别的字符串都被解释为它前面有tformat:。例如,这两个是等价的:

    $ git log -2 --pretty=tformat:%h 4da45bef
    $ git log -2 --pretty=%h 4da45bef
    

GIT

部分 git [1] 套件

git-rev-parse

原文: git-scm.com/docs/git-rev-parse

名称

git-rev-parse - 挑选和按摩参数

概要

git rev-parse [<options>] <args>…​

描述

许多 Git 瓷器命令采用混合标志(即以破折号 - 开头的参数)和用于内部使用的底层 git rev-list 命令的参数以及用于标记和参数的参数。他们在 git rev-list 下游使用的其他命令。此命令用于区分它们。

OPTIONS

操作模式

这些选项中的每一个都必须首先出现在命令行中。

 --parseopt 

在选项解析模式下使用 git rev-parse (参见下面的 PARSEOPT 部分)。

 --sq-quote 

在 shell 引用模式下使用 git rev-parse (参见下面的 SQ-QUOTE 部分)。与下面的--sq选项相比,此模式仅引用。命令输入没有其他任何操作。

--parseopt 的选项

 --keep-dashdash 

仅在--parseopt模式下有意义。告诉选项解析器回显第一个--遇到而不是跳过它。

 --stop-at-non-option 

仅在--parseopt模式下有意义。允许选项解析器在第一个非选项参数处停止。这可用于解析自带选项的子命令。

 --stuck-long 

仅在--parseopt模式下有意义。如果可用,以长格式输出选项,并且参数卡住。

过滤选项

 --revs-only 

不要输出不适用于 git rev-list 命令的标志和参数。

 --no-revs 

不要输出 git rev-list 命令的标志和参数。

 --flags 

不要输出非标志参数。

 --no-flags 

不要输出标志参数。

输出选项

 --default <arg> 

如果用户没有给出参数,请改用&lt;arg&gt;

 --prefix <arg> 

表现为好像从工作树的&lt;arg&gt;子目录调用了 git rev-parse 。任何相对文件名都被解析为好像它们以&lt;arg&gt;为前缀,并将以该格式打印。

这可用于将参数转换为子目录中运行的命令,以便在移动到存储库的顶级后仍可使用它们。例如:

prefix=$(git rev-parse --show-prefix)
cd "$(git rev-parse --show-toplevel)"
# rev-parse provides the -- needed for 'set'
eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")"
 --verify 

验证是否提供了一个参数,并且可以将其转换为可用于访问对象数据库的原始 20 字节 SHA-1。如果是这样,将其发射到标准输出;否则,错误。

如果要确保输出实际命名对象数据库中的对象和/或可以用作所需的特定对象类型,可以将^{type}剥离运算符添加到参数中。例如,git rev-parse "$VAR^{commit}"将确保$VAR命名为 commit-ish 的现有对象(即提交或指向提交的带注释标记)。为了确保$VAR命名任何类型的现有对象,可以使用git rev-parse "$VAR^{object}"

 -q 
 --quiet 

仅在--verify模式下有意义。如果第一个参数不是有效的对象名,请不要输出错误消息;而是以静默方式退出非零状态。有效对象名称的 SHA-1 在成功时打印到 stdout。

 --sq 

通常每个标志和参数输出一行。此选项使输出成为一行,正确引用以供 shell 使用。当你希望你的参数包含空格和换行符时很有用(例如当使用 pickaxe -Sgit diff- * 时)。与--sq-quote选项相反,命令输入仍然像往常一样解释。

 --short[=length] 

--verify相同,但将对象名称缩短为至少包含length字符的唯一前缀。最小长度为 4,默认值为core.abbrev配置变量的有效值(参见 git-config [1] )。

 --not 

显示对象名称时,请在 ^ 前面添加前缀,并从已有的对象名称中删除 ^ 前缀。

 --abbrev-ref[=(strict|loose)] 

对象名称的非模糊短名称。选项 core.warnAmbiguousRefs 用于选择严格的缩写模式。

 --symbolic 

通常,对象名称以 SHA-1 形式输出(可能有 ^ 前缀);此选项使它们以尽可能接近原始输入的形式输出。

 --symbolic-full-name 

这类似于--symbolic,但它省略了不是引用的输入(即分支或标记名称;或者更明确地消除歧义“head / master”形式,当您想要命名“master”分支时,有一个不幸的命名标记“master”),并将它们显示为完整的重新命名(例如“refs / heads / master”)。

对象选项

 --all 

显示refs/中找到的所有引用。

 --branches[=pattern] 
 --tags[=pattern] 
 --remotes[=pattern] 

分别显示所有分支,标签或远程跟踪分支(即分别在refs/headsrefs/tagsrefs/remotes中找到的 refs)。

如果给出pattern,则仅显示与给定 shell glob 匹配的 refs。如果模式不包含通配符(?*[),则通过附加/*将其转换为前缀匹配。

 --glob=pattern 

显示与 shell glob 模式pattern匹配的所有引用。如果模式不以refs/开头,则会自动添加前缀。如果模式不包含通配符(?*[),则通过附加/*将其转换为前缀匹配。

 --exclude=<glob-pattern> 

不包括引用匹配 < glob-pattern> 否则会考虑下一个--all--branches--tags--remotes--glob。重复此选项会累积排除模式,直至下一个--all--branches--tags--remotes--glob选项(其他选项或参数不会清除累积模式)。

当应用于--branches--tags--remotes时,给出的模式不应以refs/headsrefs/tagsrefs/remotes开始,并且当应用于--glob时,它们必须以refs/开头]或--all。如果打算使用尾随 / * ,则必须明确给出。

 --disambiguate=<prefix> 

显示名称以给定前缀开头的每个对象。 <前缀>必须至少有 4 个十六进制数字才能避免错误地列出存储库中的每个对象。

文件选项

 --local-env-vars 

列出存储库本地的 GIT_ *环境变量(例如 GIT_DIR 或 GIT_WORK_TREE,但不是 GIT_EDITOR)。仅列出变量的名称,而不是它们的值,即使它们已设置。

 --git-dir 

如果已定义,则显示$GIT_DIR。否则显示.git 目录的路径。显示的路径,相对时,相对于当前工作目录。

如果未定义$GIT_DIR并且未检测到当前目录位于 Git 存储库或工作树中,则将消息打印到 stderr 并以非零状态退出。

 --absolute-git-dir 

--git-dir类似,但其输出始终是规范化的绝对​​路径。

 --git-common-dir 

如果已定义则显示$GIT_COMMON_DIR,否则显示$GIT_DIR

 --is-inside-git-dir 

当前工作目录低于存储库目录时打印“true”,否则为“false”。

 --is-inside-work-tree 

当前工作目录在存储库的工作树内打印“true”,否则为“false”。

 --is-bare-repository 

当存储库裸露时为“true”,否则为“false”。

 --is-shallow-repository 

当存储库浅时打印“true”,否则为“false”。

 --resolve-git-dir <path> 

检查< path>是指向有效存储库的有效存储库或 gitfile,并打印存储库的位置。如果< path>是一个 gitfile 然后打印到真实存储库的已解析路径。

 --git-path <path> 

解析“$ GIT_DIR /< path>”并考虑其他路径重定位变量,如$ GIT_OBJECT_DIRECTORY,$ GIT_INDEX_FILE ....例如,如果$ GIT_OBJECT_DIRECTORY 设置为/ foo / bar,则“git rev-parse --git-path objects / abc”返回/ foo / bar / abc。

 --show-cdup 

从子目录调用该命令时,显示相对于当前目录的顶级目录的路径(通常是“../”序列或空字符串)。

 --show-prefix 

从子目录调用该命令时,显示当前目录相对于顶级目录的路径。

 --show-toplevel 

显示顶级目录的绝对路径。

 --show-superproject-working-tree 

显示使用当前存储库作为其子模块的超级项目工作树(如果存在)的根的绝对路径。如果当前存储库未被任何项目用作子模块,则不输出任何内容。

 --shared-index-path 

在拆分索引模式下显示共享索引文件的路径,如果不在拆分索引模式下则显示为空。

其他选择

 --since=datestring 
 --after=datestring 

解析日期字符串,并为 git rev-list 输出相应的--max-age =参数。

 --until=datestring 
 --before=datestring 

解析日期字符串,并为 git rev-list 输出相应的--min-age =参数。

 <args>…​ 

要解析的标志和参数。

指定修订

修订参数 < rev> 通常(但不一定)命名提交对象。它使用所谓的 _ 扩展 SHA-1_ 语法。以下是拼写对象名称的各种方法。列表末尾附近列出的名称包含提交中包含的树和 blob。

| 注意 | 本文档显示了 git 看到的“原始”语法。 shell 和其他 UI 可能需要额外的引用来保护特殊字符并避免单词拆分。 |

 <sha1>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e 

完整的 SHA-1 对象名称(40 字节十六进制字符串),或存储库中唯一的前导子字符串。例如。如果存储库中没有其他对象以 dae86e 开头的对象,则 dae86e1950b1277e545cee180551750029cfe735 和 dae86e 都命名相同的提交对象。

 <describeOutput>, e.g. v1.7.4.2-679-g3bee7fb 

git describe的输出;即,最接近的标签,可选地后跟破折号和多次提交,然后是破折号, g 和缩写的对象名称。

 <refname>, e.g. master, heads/master, refs/heads/master 

一个象征性的引用名称。例如。 master 通常表示 refs / heads / master 引用的提交对象。如果您碰巧同时拥有 _ 磁头/主控 _ 和 _ 标签/主控 ,您可以明确地说 _ 磁头/主控 _ 告诉 Git 您的意思。当含糊不清时,< refname>_ 通过以下规则中的第一场比赛消除歧义:

  1. 如果 $ GIT_DIR /< refname> 存在,这就是你的意思(这通常只适用于HEADFETCH_HEADORIG_HEADMERGE_HEADCHERRY_PICK_HEAD);

  2. 否则, refs /< refname> 如果存在;

  3. 否则, refs / tags /< refname> 如果存在;

  4. 否则, refs / heads /< refname> 如果存在;

  5. 否则, refs / remotes /< refname> 如果存在;

  6. 否则, refs / remotes /< refname> / HEAD (如果存在)。

    HEAD命名您基于工作树中的更改的提交。 FETCH_HEAD记录您使用上次git fetch调用从远程存储库中获取的分支。 ORIG_HEAD是由以大刀阔斧的方式移动HEAD的命令创建的,用于在操作之前记录HEAD的位置,以便您可以轻松地将分支的尖端更改回运行它们之前的状态。 MERGE_HEAD在运行git merge时记录您要合并到分支中的提交。当您运行git cherry-pick时,CHERRY_PICK_HEAD会记录您正在挑选的提交。

    请注意,上述任何 refs / * 情况可能来自 $ GIT_DIR / refs 目录或来自 $ GIT_DIR / packed-refs 文件。虽然未指定引用名称编码,但首选 UTF-8,因为某些输出处理可能会假定使用 UTF-8 中的引用名称。

 @ 

单独 @HEAD的捷径。

 <refname>@{<date>}, e.g. master@{yesterday}, HEAD@{5 minutes ago} 

引用后跟 @ 后缀为日期规格括号对(例如 {昨天}{1 个月 2 周 3 天 1 小时 1 秒前}{1979-02-26 18:30:00} )指定先前时间点的 ref 值。此后缀只能在引用名称后立即使用,并且引用必须具有现有日志( $ GIT_DIR / logs /< ref> )。请注意,这会在给定时间查找本地 ref 的状态;例如,上周本地 _ 主 _ 分支机构的内容。如果要查看在特定时间内提交的提交,请参阅--since--until

 <refname>@{<n>}, e.g. master@{1} 

后缀为 @ 的后缀为括号对中的序数规范(例如 {1}{15} )指定第 n 个先验那个参考的价值。例如 master @ {1}master 的前一个值,而 master @ {5}master 的第 5 个先前值]。此后缀只能在引用名称后立即使用,并且引用必须具有现有日志( $ GIT_DIR / logs /< refname> )。

 @{<n>}, e.g. @{1} 

您可以使用带有空参考部分的 @ 构造来获取当前分支的 reflog 条目。例如,如果你在分支 blabla ,那么 @ {1} 意味着与 blabla @ {1} 相同。

 @{-<n>}, e.g. @{-1} 

构造 @ { - < n>} 表示在当前分支/提交之前检出的第 n 个分支/提交。

 <branchname>@{upstream}, e.g. master@{upstream}, @{u} 

后缀 @ {upstream} 到分支机构(简称 < branchname> @ {u} )指的是由 branchname 指定的分支设置为在其上构建的分支(配置为branch.&lt;name&gt;.remotebranch.&lt;name&gt;.merge)。缺少的 branchname 默认为当前的。当拼写为大写时,这些后缀也被接受,无论如何它们都意味着相同的东西。

 <branchname>@{push}, e.g. master@{push}, @{push} 

后缀 @ {push} 报告分支“我们将推送到哪里”如果branchnamebranchname被检出时运行(或者当前HEAD如果没有指定分支机构)。由于我们的推送目的地位于远程存储库中,当然,我们报告与该分支对应的本地跟踪分支(即 refs / remotes / 中的内容)。

这是一个让它更清晰的例子:

$ git config push.default current
$ git config remote.pushdefault myfork
$ git checkout -b mybranch origin/master

$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master

$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch

请注意,在我们设置三角形工作流程的示例中,我们从一个位置拉出并推送到另一个位置。在非三角形工作流程中, @ {push}@ {upstream} 相同,并且不需要它。

拼写为大写时也接受此后缀,无论情况如何都是相同的。

 <rev>^, e.g. HEAD^, v1.5.1⁰ 

修订参数的后缀 ^ 表示该提交对象的第一个父级。 ^< n> 表示第 n 个亲本(即 < rev> ^ 等同于 < rev> ^ )。作为特殊规则,< rev> ^ 0 表示提交本身并且在 < rev>时使用。 是引用提交对象的标记对象的对象名称。

 <rev>~<n>, e.g. master~3 

后缀 〜< n> 到版本参数意味着提交对象是指定提交对象的第 n 代祖先,仅跟随第一个父对象。即 < rev>〜 相当于 < rev> ^^^ ,其相当于 < rev> ^ 1 ^ 1 ^ 。请参阅下文,了解此表单的用法。

 <rev>^{<type>}, e.g. v0.99.8^{commit} 

后缀 ^ 后跟括号对中包含的对象类型名称意味着在 < rev>处取消引用对象。 递归地直到 < type>类型的对象为止。找到 _ 或者不再解除引用对象(在这种情况下,barf)。例如,如果 < rev> 是 commit-ish,< rev> ^ {commit}_ 描述了相应的提交对象。类似地,如果 < rev> 是树,< rev> ^ {tree} 描述了相应的树对象。 < rev> ^ 0< rev> ^ {commit} 的简写。

rev ^ {object} 可以用来确保 rev 命名一个存在的对象,而不需要 rev 作为标签,并且不需要解除引用 rev ;因为标签已经是一个对象,所以即使一次到达一个对象也不需要解除引用。

rev ^ {tag} 可用于确保 rev 标识现有标记对象。

 <rev>^{}, e.g. v0.99.8^{} 

后缀 ^ 后跟空括号对意味着该对象可以是标记,并递归取消引用标记,直到找到非标记对象。

 <rev>^{/<text>}, e.g. HEAD^{/fix nasty bug} 

后缀 ^ 到一个修订参数,后跟一个括号对,其中包含一个由斜杠引导的文本,与下面的 _:/ fix 讨厌错误 _ 语法相同,只是它返回可以从 _< rev>到达的最年轻的匹配提交 ^ 之前的 _。

 :/<text>, e.g. :/fix nasty bug 

冒号后跟一个斜杠,后跟一个文本,命名一个提交,其提交消息与指定的正则表达式匹配。此名称返回可从任何 ref 访问的最新匹配提交,包括 HEAD。正则表达式可以匹配提交消息的任何部分。为了匹配以字符串开头的消息,可以使用例如 :/ ^ foo 。特殊序列 :/! 保留用于匹配的修饰符。 :/! - foo 执行负匹配,而 :/ !! foo 匹配文字 字符,然后是 foo 。以 _ 开头的任何其他序列:/!_ 暂时保留。根据给定的文本,shell 的单词拆分规则可能需要额外的引用。

 <rev>:<path>, e.g. HEAD:README, :README, master:./README 

后缀 后跟一个路径,命名由冒号前部分命名的树形对象中给定路径上的 blob 或树。 :path (在冒号前面有空部分)是下面描述的语法的特例:在给定路径的索引中记录的内容。以 ./../ 开头的路径是相对于当前工作目录的。给定路径将转换为相对于工作树的根目录。这对于从具有与工作树具有相同树结构的提交或树来解决 blob 或树最有用。

 :<n>:<path>, e.g. :0:README, :README 

冒号,可选地后跟一个阶段号(0 到 3)和一个冒号,后跟一个路径,在给定路径的索引中命名一个 blob 对象。缺少的阶段编号(以及其后面的冒号)命名阶段 0 条目。在合并期间,阶段 1 是共同的祖先,阶段 2 是目标分支的版本(通常是当前分支),阶段 3 是正在合并的分支的版本。

以下是 Jon Loeliger 的插图。提交节点 B 和 C 都是提交节点 A 的父节点。父提交从左到右排序。

G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
         A
A =      = A⁰
B = A^   = A¹     = A~1
C = A²  = A²
D = A^^  = A¹¹   = A~2
E = B²  = A^²
F = B³  = A^³
G = A^^^ = A¹¹¹ = A~3
H = D²  = B^²    = A^^²  = A~2²
I = F^   = B³^    = A^³^
J = F²  = B³²   = A^³²

指定范围

遍历诸如git log之类的命令的历史操作在一组提交上,而不仅仅是单个提交。

对于这些命令,使用上一节中描述的表示法指定单个修订版意味着来自给定提交的提交reachable集。

提交的可达集是提交本身和其祖先链中的提交。

提交排除

 ^<rev> (caret) Notation 

要排除从提交可到达的提交,使用前缀 ^ 表示法。例如。 ^ r1 r2 表示从 r2 可到达的提交,但排除可从 r1 (即 r1 及其祖先)到达的提交。

虚线范围符号

 The .. (two-dot) Range Notation 

^ r1 r2 设置操作经常出现,因此有一个简写。如果你有两个提交 r1r2 (根据上面的 SPECIFYING REVISIONS 中解释的语法命名),你可以要求从 r2 可以访问的提交,不包括那些可以从 r1 到达的提交 ^ r1 r2 可以写成 r1..r2

 The …​ (three-dot) Symmetric Difference Notation 

类似的符号 r1 ... r2 称为 r1r2 的对称差异,定义为 r1 r2 - not $(git merge) -base --all r1 r2)。它是可以从 r1 (左侧)或 r2 (右侧)中的任何一个到达的提交集,但不是两者都可以。

在这两个简写符号中,您可以省略一端并将其默认为 HEAD。例如,_ 原点.._ 是 origin..HEAD 的简写并询问“自从我从原点分支分叉后我做了什么?”同样, .originHEAD..origin 的简写,并询问“自从我从它们分叉后,起源做了什么?”注意 .. 将意味着 HEAD..HEAD ,这是一个空的范围,既可以从 HEAD 到达又无法到达。

其他< rev> ^父简写符号

存在三个其他的缩写,对于合并提交特别有用,用于命名由提交及其父提交形成的集合。

r1 ^ @ 符号表示 r1 的所有亲本。

r1 ^! 表示法包含 commit r1 但不包括其所有父母。这个符号本身表示单个提交 r1

< rev> ^ - < n> 符号包括 < rev> 但不包括第 n 个亲本(即 < rev> ^< n> ..< rev> 的简写),< n>如果没有给出, = 1。这通常对于合并提交很有用,您可以通过 < commit> ^ - 来获取合并提交中合并的分支中的所有提交 < commit> (包括 < commit> 本身)。

虽然 < rev> ^< n> 是关于指定单个提交父级,这三个符号也考虑其父级。例如你可以说 HEAD ^ 2 ^ @ ,但你不能说 HEAD ^ @ ^ 2

修订范围摘要

 <rev> 

包括可从< rev>到达的提交(即< rev>及其祖先)。

 ^<rev> 

排除可从< rev>到达的提交(即< rev>及其祖先)。

 <rev1>..<rev2> 

包括可从< rev2>到达的提交但不包括那些可以从< rev1>到达的那些。何时< rev1>或者< rev2>省略,默认为HEAD

 <rev1>...<rev2> 

包括可从< rev1>到达的提交或者< rev2>但排除那两个可以访问的。何时< rev1>或者< rev2>省略,默认为HEAD

 <rev>^@, e.g. HEAD^@ 

后缀为 ^ 后跟 at 符号与列出 < rev>的所有父项相同。 (意思是,包括从其父母可以访问的任何内容,但不包括提交本身)。

 <rev>^!, e.g. HEAD^! 

后缀为 ^ 后跟感叹号与提交 < rev>相同。 然后它的所有父母都以 ^ 为前缀来排除它们(以及它们的祖先)。

 <rev>^-<n>, e.g. HEAD^-, HEAD^-2 

等同于 < rev> ^< n> ..< rev>< n>如果没有给出, = 1。

以下是使用上面的 Loeliger 插图的一些示例,其中注释的扩展和选择中的每个步骤都经过仔细说明:

   Args   Expanded arguments    Selected commits
   D                            G H D
   D F                          G H I J D F
   ^G D                         H D
   ^D B                         E I J F B
   ^D B C                       E I J F B C
   C                            I J F C
   B..C   = ^B C                C
   B...C  = B ^F C              G H D E B C
   B^-    = B^..B
	  = ^B¹ B              E I J F B
   C^@    = C¹
	  = F                   I J F
   B^@    = B¹ B² B³
	  = D E F               D G H E F I J
   C^!    = C ^C^@
	  = C ^C¹
	  = C ^F                C
   B^!    = B ^B^@
	  = B ^B¹ ^B² ^B³
	  = B ^D ^E ^F          B
   F^! D  = F ^I ^J D           G H D F

PARSEOPT

--parseopt模式下, git rev-parse 帮助按摩选项为 C 脚本提供相同的设施。它作为一个选项规范化器(例如拆分单个开关聚合值),有点像getopt(1)

它采用标准输入来解析和理解选项的规范,并在标准输出上回显适合sh(1) eval的字符串,用规范化的参数替换参数。如果出现错误,它会输出标准错误流的使用情况,并以代码 129 退出。

注意:确保在将结果传递给eval时引用结果。请参阅下面的示例。

输入格式

git rev-parse --parseopt 输入格式是完全基于文本的。它有两个部分,由仅包含--的线分隔。分隔符之前的行(应该是一个或多个)用于使用。分隔符后面的行描述了选项。

每行选项都有这种格式:

<opt-spec><flags>*<arg-hint>? SP+ help LF
 <opt-spec> 

它的格式是短选项字符,然后用逗号分隔的长选项名称。两个部件都不是必需的,但至少需要一个部件。不得包含任何&lt;flags&gt;字符。 h,helpdry-runf是正确的&lt;opt-spec&gt;的例子。

 <flags> 

&lt;flags&gt;属于*=?!

  • 如果选项采用参数,请使用=

  • 使用?表示该选项采用可选参数。您可能希望使用--stuck-long模式能够明确地解析可选参数。

  • 使用*表示不应在为-h参数生成的用法中列出此选项。 gitcli [7] 中记载的--help-all显示了它。

  • 使用!不会使相应的否定长选项可用。

 <arg-hint> 

&lt;arg-hint&gt;(如果指定)用作帮助输出中参数的名称,用于带参数的选项。 &lt;arg-hint&gt;由第一个空格终止。习惯上使用短划线来分隔多字参数提示中的单词。

剥离空格后,该行的其余部分用作与选项关联的帮助。

空行被忽略,与此规范不匹配的行将用作选项组标题(使用空格开始行以有意创建此类行)。

OPTS_SPEC="\
some-command [<options>] <args>...

some-command does foo and bar!
--
h,help    show the help

foo       some nifty option --foo
bar=      some cool option --bar with an argument
baz=arg   another cool option --baz with a named argument
qux?path  qux may take a path argument but has meaning by itself

  An option group Header
C?        option C with an optional argument"

eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"

用法文字

在上例中"$@"-h--help时,将显示以下用法文本:

usage: some-command [<options>] <args>...

    some-command does foo and bar!

    -h, --help            show the help
    --foo                 some nifty option --foo
    --bar ...             some cool option --bar with an argument
    --baz <arg>           another cool option --baz with a named argument
    --qux[=<path>]        qux may take a path argument but has meaning by itself

An option group Header
    -C[...]               option C with an optional argument

SQ-QUOTE

--sq-quote模式下, git rev-parse 在标准输出上回显适合sh(1) eval的单行。该行是通过规范化--sq-quote之后的参数来完成的。除了引用参数之外别无其他。

如果您希望在输出引用 shell 之前 git rev-parse 仍然按常规解释命令输入,请参阅--sq选项。

$ cat >your-git-script.sh <<\EOF
#!/bin/sh
args=$(git rev-parse --sq-quote "$@")   # quote user-supplied arguments
command="git frotz -n24 $args"          # and use it inside a handcrafted
					# command line
eval "$command"
EOF

$ sh your-git-script.sh "a b'c"

例子

  • 打印当前提交的对象名称:

    $ git rev-parse --verify HEAD
    
  • 从$ REV shell 变量中的修订版打印提交对象名称:

    $ git rev-parse --verify $REV^{commit}
    

    如果$ REV 为空或不是有效修订,则会出错。

  • 与上面类似:

    $ git rev-parse --default master --verify $REV
    

    但是如果$ REV 为空,则将打印来自 master 的提交对象名称。

GIT

部分 git [1] 套件

posted @ 2024-06-23 00:15  绝不原创的飞龙  阅读(4)  评论(0编辑  收藏  举报