Git 中文参考(一)(3)https://developer.aliyun.com/article/1565872
示例
# Core variables [core] ; Don't trust file modes filemode = false
# Our diff algorithm [diff] external = /usr/local/bin/diff-wrapper renames = true
[branch "devel"] remote = origin merge = refs/heads/devel
# Proxy settings [core] gitProxy="ssh" for "kernel.org" gitProxy=default-proxy ; for the rest
[include] path = /path/to/foo.inc ; include by absolute path path = foo.inc ; find "foo.inc" relative to the current file path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory
; include if $GIT_DIR is /path/to/foo/.git [includeIf "gitdir:/path/to/foo/.git"] path = /path/to/foo.inc
; include for all repositories inside /path/to/group [includeIf "gitdir:/path/to/group/"] path = /path/to/foo.inc
; include for all repositories inside $HOME/to/group [includeIf "gitdir:~/to/group/"] path = /path/to/foo.inc
; relative paths are always relative to the including ; file (if the condition is true); their location is not ; affected by the condition [includeIf "gitdir:/path/to/group/"] path = foo.inc
值
许多变量的值被视为一个简单的字符串,但是有些变量采用特定类型的值,并且有关于如何拼写它们的规则。
boolean
当一个变量被认为是一个布尔值时,true 和 false 接受许多同义词;这些都是不区分大小写的。
true
字面意思是yes
,on
,true
和1
。此外,变量没有定义=
的话,默认值是 true。
false
字面意思是no
,off
,false
,0
和空字符串。
使用--type=bool
类型说明符将值转换为规范形式时,git config 将确保输出为“true”或“false”(拼写为小写)。
integer
指定各种大小的许多变量的值可以后缀为k
,M
,表示“将数字扩大 1024 倍”,“1024x1024 倍”等。
color
采用颜色的变量的值是一个颜色列表(最多两个,一个用于前景,一个用于背景)和属性(多个您想要的),用空格分隔。
接受的基本颜色是normal
,black
,red
,green
,yellow
,blue
,magenta
,cyan
和white
。给出的第一种颜色是前景,第二是背景。
颜色也可以作为 0 到 255 之间的数字给出,这些使用 ANSI 256 色模式(但请注意,并非所有终端都支持此功能)。如果您的终端支持它,您也可以将 24 位 RGB 值指定为十六进制,如#ff0ab3
。
接受的属性有bold
,dim
,ul
,blink
,reverse
,italic
和strike
(用于划掉或“删除”字母)。任何属性相对于颜色(之前,之后或之间)的位置都无关紧要。可以通过在前缀no
或no-
(例如,noreverse
,no-ul
等)来关闭特定属性。
空颜色字符串根本不产生颜色效果。这可用于避免在不完全禁用颜色的情况下着色特定元素。
对于 git 的预定义颜色槽,属性应在彩色输出中每个项目的开头重置。因此,将color.decorate.branch
设置为black
将在普通black
中绘制该分支名称,即使同一输出行上的前一项(例如log --decorate
输出中的分支名称列表前的左括号)设置为被涂上bold
或其他一些属性。但是,自定义日志格式可能会执行更复杂和分层的着色,而否定的格式在那里可能会有用。
pathname
获取路径名值的变量可以被赋予以“~/
”或“~user/
”开头的字符串,并且通常的波浪号扩展发生在这样的字符串中:~/
扩展为$HOME
的值,~user/
为指定用户的根目录。
变量
请注意,此列表不全面,不一定完整。对于特定于命令的变量,您可以在相应的手册页中找到更详细的说明。
其他与 git 相关的工具可能并且确实使用它们自己的变量。在发明用于您自己的工具的新变量时,请确保它们的名称与 Git 本身和其他常用工具使用的名称不冲突,并在文档中对其进行描述。
advice.*
这些变量控制旨在帮助新用户的各种可选帮助消息。所有 advice.* 变量默认为 true,你可以通过将这些设置为false
告诉 Git 你不需要帮助:
pushUpdateRejected
如果要同时禁用 pushNonFFCurrent,pushNonFFMatching , pushAlreadyExists ,和 pushFetchFirst,和 pushNeedsForce 变量,请将此变量设置为 false。
pushNonFFCurrent
当 git-push [1] 由于对当前分支的非快进更新而失败时显示的建议。
pushNonFFMatching
当您运行 git-push [1] 并显式推送 _ 匹配 refs_ 时显示的建议(即您使用 :,或指定了不是您当前的 refspe 分支)并导致非快进错误。
pushAlreadyExists
当 git-push [1] 拒绝不符合快进条件的更新(例如,标签)时显示。
pushFetchFirst
当 git-push [1] 拒绝尝试覆盖指向我们没有的对象的远程引用的更新时显示。
pushNeedsForce
当 git-push [1] 拒绝尝试覆盖指向不是 commit-ish 的对象的远程 ref 的更新时,或者在不是 commit-ish 的对象上进行远程 ref 操作。
pushUnqualifiedRefname
当 git-push [1] 放弃尝试根据源和目标进行猜测时显示源所属的远程 ref 命名空间,但我们仍然可以建议用户推送到 refs/heads/* 或 refs/tags/*基于源对象的类型。
statusHints
在 git-commit [1] 中写入提交消息时显示的模板中显示如何从 git-status [1] 的输出中的当前状态开始的指示,以及切换分支时,git-checkout [1] 显示的帮助信息。
statusUoption
建议考虑在 git-status [1] 中使用-u
选项,当命令需要超过 2 秒来枚举未跟踪文件时。
commitBeforeMerge
当 git-merge [1] 拒绝合并以避免覆盖本地更改时显示的建议。
resetQuiet
建议考虑在 git-reset [1] 中使用--quiet
选项,当命令需要 2 秒以上的时间来枚举复位后的非分段更改时。
resolveConflict
当冲突阻止执行操作时,各种命令显示的建议。
implicitIdentity
在从系统用户名和域名中猜出您的信息时,如何设置身份配置的建议。
detachedHead
使用 git-checkout [1] 移动到分离 HEAD 状态时显示的建议,以指示如何在事后创建本地分支。
checkoutAmbiguousRemoteBranchName
当 git-checkout [1] 的参数,在有多个远端的场景下,模糊地解析为远程跟踪分支时,如果明确的参数会导致远程跟踪分支被检出,则显示建议。请参阅checkout.defaultRemote
配置变量,如何在给定远端的某些场景下使用。
amWorkDir
当 git-am [1] 无法应用时,显示补丁文件位置的建议。
rmHints
如果 git-rm [1] 的输出失败,请显示如何从当前状态开始的指示。
addEmbeddedRepo
当你意外地在另一个内部添加一个 git repo 时该怎么做的建议。
ignoredHook
如果钩子被忽略,则显示建议,因为钩子未设置为可执行文件。
waitingForEditor
只要 Git 正在等待用户的编辑输入,就将消息打印到终端。
core.fileMode
告诉 Git 是否要遵守工作树中文件的可执行权限。
当检出标记为可执行的文件,或者以可执行权限检出非可执行文件时,在某些文件系统中会丢失可执行权限。 git-clone [1] 或 git-init [1] 会探测当前文件系统,看它是否能正确处理文件权限,并根据需要自动设置此变量。
但是,存储库可能位于正确处理文件模式的文件系统上,并且此变量在开始配置时设置为 true ,但稍后从其他环境访问可能会失去文件模式的设置(例如,通过导出 CIFS 挂载的 ext4 ,使用 Git for Windows 或 Eclipse 访问 Cygwin 创建的存储库)。在这种情况下,可能需要将此变量设置为 false 。参见 git-update-index [1] 。
默认值为 true(在配置文件中未指定 core.filemode 时)。
core.hideDotFiles
(仅限 Windows)如果为 true,将标记新创建的、以点开头的命名的目录和文件为隐藏。如果 dotGitOnly ,则只隐藏.git/
目录,但没有其他以点开头的文件。默认模式为 dotGitOnly 。
core.ignoreCase
内部变量,支持各种变通方法,使 Git 能够更好地处理不区分大小写的文件系统,如 APFS,HFS +,FAT,NTFS 等。例如,如果要在某个目录列表下找出“makefile”文件,Git 会将“Makefile”输出,Git 认为它们是同一个文件,并继续记住它为“Makefile”。
默认值为 false,除了 git-clone [1] 或 git-init [1] 将在创建存储库时预测并设置 core.ignoreCase 为 true。
在您的操作系统和文件系统上,Git 依赖于正确配置此变量的值。修改此值可能会导致意外后果。
core.precomposeUnicode
此选项仅供 Mac OS 实现 Git 使用。当 core.precomposeUnicode = true 时,Git 会恢复 Mac OS 上以 unicode 分解的文件名。在 Mac OS、Linux 或 Windows 之间共享存储库时,这非常有用。(需要适用于 Windows 1.7.10 或更高版本的 Git,或者在 cygwin 1.7 下使用 Git)。如果为 false,则 Git 会完全透明文件名,后者与旧版本的 Git 向后兼容。
core.protectHFS
如果设置为 true,在 HFS+文件系统上,则不允许检出文件路径,会被视为等同于.git
的路径。在 Mac OS 上默认为true
,在其他地方默认为false
。
core.protectNTFS
如果设置为 true,则不允许签出可能导致 NTFS 文件系统出现问题的路径,例如:与 8.3“short”冲突的名称。在 Windows 上默认为true
,在其他地方默认为false
。
core.fsmonitor
如果设置,则此变量的值将用作命令,该命令将标识自请求的日期/时间以来可能已更改的所有文件。此信息用于通过避免对未更改的文件进行不必要的处理来加速 git 操作。请参阅 githooks [5] 的“fsmonitor-watchman”部分。
core.trustctime
如果为 false,则忽略索引与工作树之间的 ctime 差异;当 inode 更改时间被 Git 之外的某些东西(文件系统爬虫和一些备份系统)定期修改时,将非常有用。参见 git-update-index [1] 。默认为 True。
core.splitIndex
如果为 true,则将使用索引的拆分索引功能。参见 git-update-index [1] 。默认为 False。
core.untrackedCache
确定如何处理索引的未跟踪缓存功能。如果未设置此变量或将其设置为keep
,则将保留该值。如果设置为true
,将自动添加。如果设置为false
,它将自动删除。在将其设置为true
之前,您应该检查 mtime 是否在您的系统上正常工作。参见 git-update-index [1] 。 keep
默认情况下。
core.checkStat
当缺失或设置为default
时,将检查 stat 结构中的许多字段以检测文件是否已被修改,因为 Git 查看了它。当此配置变量设置为minimal
时,mtime 和 ctime 的亚秒部分,文件所有者的 uid 和 gid,inode 编号(以及设备编号,如果 Git 编译为使用它),从这些字段中的检查中排除,只留下 mtime 的整个第二部分(和 ctime,如果设置了core.trustCtime
)和要检查的文件大小。
Git 的实现不会在某些字段中留下可用的值(例如 JGit);通过从比较中排除这些字段,当同个仓库在被其他系统使用时,minimal
模式可以帮助实现互操作性。
core.quotePath
输出路径的命令(例如 ls-files , diff )将在路径名中引用“异常”字符,方法是将路径名括在双引号中并使用反斜杠转义那些字符。和在 C 语言中转义控制字符(例如 TAB 为\t
,LF 为\n
,反斜杠为\\
)或值大于 0x80 的字节(例如,UTF-8 中为“micro”的八进制\302\265
)使用的同样的方法。如果此变量设置为 false,则高于 0x80 的字节不再被视为“异常”。无论此变量的设置如何,双引号,反斜杠和控制字符始终都会被转义。简单的空格字符不被视为“不寻常”。许多命令可以使用-z
选项完全逐字输出路径名。默认值是 true。
core.eol
设置要在工作目录中用于标记为文本的文件的行结束类型(通过设置text
属性,或者使text=auto
和 Git 自动检测内容为文本)。替代品是 lf , crlf 和 native,它使用平台的原生的行结束符。默认值为native
。有关行尾转换的更多信息,请参见 gitattributes [5] 。请注意,如果core.autocrlf
设置为true
或input
,则忽略该值。
core.safecrlf
如果为 true,则当行结束转换处于活动状态时,使 Git 检查转换CRLF
是否可逆。 Git 将验证命令是直接还是间接修改工作树中的文件。例如,提交文件后检出同一文件应该会在工作树中生成原始文件。如果core.autocrlf
的当前设置不是这种情况,Git 将拒绝该文件。该变量可以设置为“警告”,在这种情况下,Git 只会警告不可逆转换,但继续操作。
CRLF 转换有可能破坏数据。启用时,Git 会在提交期间将 CRLF 转换为 LF,在检出时将 LF 转换为 CRLF。 Git 无法重新创建提交之前包含 LF 和 CRLF 混合的文件。对于文本文件,正确的做法是:它校正行结尾符,这样我们在存储库中只有 LF 行结尾。但对于意外归类为文本的二进制文件,转换可能会破坏数据。
如果您提前识别出此类损坏,则可以通过在.gitattributes 中明确设置转换类型来轻松解决此问题。提交后,您仍然在工作树中保留原始文件,此文件尚未损坏。你可以明确告诉 Git 这个文件是二进制文件,Git 会适当地处理文件。
不幸的是,无法区分清除具有混合行结尾的文本文件和破坏二进制文件的不良影响的期望效果。在这两种情况下,CRLF 都以不可逆转的方式被移除。对于文本文件,这是正确的做法,因为 CRLF 是行结尾,而对于二进制文件,转换 CRLF 会破坏数据。
请注意,此安全检查并不意味着在坚持文件时,将为core.eol
和core.autocrlf
的不同设置生成与原始文件相同的文件,但仅适用于当前的文件。例如,带有LF
的文本文件将被core.eol=lf
接受,之后可以使用core.eol=crlf
检出,在这种情况下,生成的文件将包含CRLF
,尽管原始文件包含LF
。但是,在两个工作树中,行结束符将是一致的,即所有LF
或全部CRLF
,但从不混合。 core.safecrlf
机制将报告具有混合行结尾的文件。
core.autocrlf
将此变量设置为“true”,与在所有文件上将text
属性设置为“auto”,并将 core.eol 设置为“crlf”相同。如果要在工作目录中包含CRLF
行结尾且存储库具有 LF 行结尾,则设置为 true。该变量可以设置为 input,在这种情况下不执行输出转换。
core.checkRoundtripEncoding
逗号和/或空格分隔的编码列表,Git 执行 UTF-8 往返检查它们是否在working-tree-encoding
属性中使用(参见 gitattributes [5] )。默认值为SHIFT-JIS
。
core.symlinks
如果为 false,则将符号链接检出为包含链接文本的小型纯文本。 git-update-index [1] 和 git-add [1] 不会将记录类型更改为常规文件。在 FAT 等不支持符号链接的文件系统上很有用。
默认值为 true,除了 git-clone [1] 或 git-init [1] 将在创建存储库时预测并设置 core.symlinks 为 false。
core.gitProxy
执行(作为 _ 命令主机端口 _)的“代理命令”,在使用 Git 协议进行更新时,将建立替代与远程服务器的直接连接方式。如果变量值在“COMMAND for DOMAIN”格式中,则该命令仅应用于以指定域字符串结尾的主机名。该变量可以多次设置并按给定顺序匹配;第一次匹配上就不继续往下匹配了。
可以被GIT_PROXY_COMMAND
环境变量覆盖(它总是普遍适用,没有特殊的“for”处理)。
特殊字符串none
可用作代理命令,以指定不为给定的域模式使用代理。这对于从代理使用中排除防火墙内的服务器非常有用,同时默认为外部域的公共代理。
core.sshCommand
如果设置了此变量,git fetch
和git push
将在需要连接到远程系统时使用指定的命令而不是ssh
。该命令与GIT_SSH_COMMAND
环境变量的格式相同,并在设置环境变量时被覆盖。
core.ignoreStat
如果为 true,Git 将避免使用 lstat()调用来检测文件是否已更改,方法是为索引和工作树中相同更新的跟踪文件设置“假定未更改”位。
当在 Git 之外修改文件时,用户将需要明确地分阶段修改文件(例如,参见 git-update-index [1] 中的 _ 示例 _ 部分)。 Git 通常不会检测这些文件的更改。
这在 lstat()调用非常慢的系统(例如 CIFS / Microsoft Windows)上很有用。
默认为 False。
core.preferSymlinkRefs
将替代 HEAD 和其他符号引用文件的默认“symref”格式,并使用符号链接。这有时需要使用期望 HEAD 成为符号链接的旧脚本。
core.alternateRefsCommand
当显示可用历史记录的提示时,将使用 shell 执行指定的命令,而不是 git-for-each-ref [1] 。第一个参数是备用的绝对路径。输出必须每行包含一个十六进制对象 id(即,与git for-each-ref --format='%(objectname)'
产生的相同)。
请注意,您通常不能将git for-each-ref
直接放入配置值,因为它不会将存储库路径作为参数(但您可以将上面的命令包装在 shell 脚本中)。
core.alternateRefsPrefixes
列出备用引用时,仅列出以给定前缀开头的引用。前缀匹配,好像它们作为 git-for-each-ref [1] 的参数给出。要列出多个前缀,请用空格分隔它们。如果设置了core.alternateRefsCommand
,则设置core.alternateRefsPrefixes
无效。
core.bare
如果为 true,则假定此存储库为 bare 并且没有与之关联的工作目录。如果是这种情况,将禁用许多与工作目录相关的命令,例如 git-add [1] 或 git-merge [1] 。
创建存储库时, git-clone [1] 或 git-init [1] 会自动预测此设置。默认情况下,假定以“/.git”结尾的存储库不是 bare(bare=false),而假定所有其他存储库都是 bare(bare=ture)。
core.worktree
设置工作树根目录的路径。如果设置了GIT_COMMON_DIR
环境变量,则会忽略 core.worktree,而不会用于确定工作树的根。这可以被GIT_WORK_TREE
环境变量和--work-tree
命令行选项覆盖。该值可以是绝对路径或相对于.git 目录的路径,该目录由–git-dir 或 GIT_DIR 指定,或自动发现。如果指定了–git-dir 或 GIT_DIR 但未指定–work-tree,GIT_WORK_TREE 和 core.worktree,则当前工作目录将被视为工作树的顶级。
请注意,即使在目录的“.git”子目录中的配置文件中设置此变量,并且其值与后一目录不同(例如“/path/to/.git/config”已将 core.worktree 设置为“/different/path”),这很可能是一个配置错误。在“/path/ to”目录中运行 Git 命令仍将使用“/different/path”作为工作树的根目录,除非您知道自己在做什么,否则可能会造成混淆(例如,您正在创建一个只读快照与存储库的通常工作树不同的位置的相同索引)。
core.logAllRefUpdates
启用 reflog。对 ref的更新记录到文件“$GIT_DIR/logs/
”,方法是附加新旧 SHA-1,日期/时间和更新原因,但仅限于文件存在时。如果此配置变量设置为true
,则会自动为分支头创建缺省的“$GIT_DIR/logs/
”文件(即在refs/heads/
下),远程 ref(即在refs/remotes/
下),评论 ref(即在refs/notes/
下) )和符号 ref HEAD
。如果设置为always
,则会自动为refs/
下的任何参考创建缺少的 reflog。
此信息可用于确定“2 天前”分支的提示是什么。
默认情况下,此值在具有与之关联的工作目录的存储库中为 true,默认情况下在空存储库中为 false。
core.repositoryFormatVersion
标识存储库格式和布局版本的内部变量。
core.sharedRepository
当 _ 组 _(或 true )时,存储库可在组中的多个用户之间共享(确保所有文件和对象都是组内可写的)。当 _ 所有 _(或 _ 世界 _ 或 _ 所有人 _)时,除了可分组之外,所有用户都可以读取存储库。当 umask (或 false )时,Git 将使用 umask(2)报告的权限。当 0xxx ,其中 0xxx 是八进制数时,存储库中的文件将具有此模式值。 0xxx 将覆盖用户的 umask 值(而其他选项只会覆盖用户的 umask 值的请求部分)。示例: 0660 将对所有者和组进行可读/可写,但其他人无法访问(相当于 _ 组 _,除非 umask 是例如 0022 ) 。 0640 是一个可读取组但不可写入组的存储库。参见 git-init [1] 。默认为 False。
core.warnAmbiguousRefs
如果为 true,Git 会警告您,如果您传递的引用名称不明确并且可能与存储库中的多个引用相匹配。默认为 True。
core.compression
整数-1…9,表示默认压缩级别。 -1 是 zlib 的默认值。 0 表示没有压缩,1…9 是各种速度/大小权衡,9 表示最慢。如果设置,则为其他压缩变量提供默认值,例如core.looseCompression
和pack.compression
。
core.looseCompression
整数-1…9,表示不在包文件中的对象的压缩级别。 -1 是 zlib 的默认值。 0 表示没有压缩,1…9 是各种速度/大小权衡,9 表示最慢。如果未设置,则默认为 core.compression。如果未设置,则默认为 1(最佳速度)。
core.packedGitWindowSize
在单个映射操作中映射到内存的 pack 文件的字节数。设置大的值时,可以允许您的系统更快地处理较少数量的大包文件。设置较小值时,会因调用操作系统内存管理器频繁,而导致对性能产生负面影响,但在访问大量大型文件包时可能会提高性能。
如果在编译时设置 NO_MMAP,则默认值为 1 MiB,否则 32 位平台上为 32 MiB,64 位平台上为 1 GiB。这应该适用于所有用户/操作系统。您可能不需要调整此值。
支持 k , m 或 g 的通用单位后缀。
core.packedGitLimit
从包文件同时映射到内存的最大字节数。如果 Git 需要一次访问多个字节以完成操作,它将取消映射现有区域以回收进程中的虚拟地址空间。
在 32 位平台上默认为 256 MiB,在 64 位平台上默认为 32 TiB(实际上无限制)。对于所有用户/操作系统,这应该是合理的,除了最大的项目。您可能不需要调整此值。
支持 k , m 或 g 的通用单位后缀。
core.deltaBaseCacheLimit
保留用于缓存可能由多个已分层对象引用的基础对象的最大字节数。通过将整个解压缩的基础对象存储在高速缓存中,Git 能够避免多次解包和解压缩经常使用的基础对象。
所有平台上的默认值为 96 MiB。对于所有用户/操作系统,这应该是合理的,除了最大的项目。您可能不需要调整此值。
支持 k , m 或 g 的通用单位后缀。
core.bigFileThreshold
大于此大小的文件将直接存储,而不会尝试增量压缩。在没有增量压缩的情况下存储大型文件可以避免过多的内存使用,但会增加磁盘使用量。此外,大于此大小的文件始终被视为二进制文件。
所有平台上的默认值为 512 MiB。对于大多数项目来说这应该是合理的,因为源代码和其他文本文件仍然可以进行增量压缩,但是更大的二进制媒体文件不会。
支持 k , m 或 g 的通用单位后缀。
core.excludesFile
除了 .gitignore (每个目录)和 .git/info/exclude 之外,还可指定包含不打算跟踪的文件路径名。默认为$XDG_CONFIG_HOME/git/ignore
。如果$XDG_CONFIG_HOME
未设置或为空,则使用$HOME/.config/git/ignore
。见 gitignore [5] 。
core.askPass
交互式地请求密码的一些命令(例如,svn 和 http 接口)可以被告知使用通过该变量的值给出的外部程序。可以被GIT_ASKPASS
环境变量覆盖。如果未设置,则回退到SSH_ASKPASS
环境变量的值,或者,如果失败,则返回一个简单的密码提示。外部程序应作为命令行参数给出合适的提示,并在其 STDOUT 上写入密码。
core.attributesFile
除了 .gitattributes (每个目录)和 .git/info/attributes 之外,Git 还会查看此文件中的属性(参见 gitattributes [5] ) 。路径扩展的方式与core.excludesFile
相同。其默认值为$XDG_CONFIG_HOME/git/attributes
。如果$XDG_CONFIG_HOME
未设置或为空,则使用$HOME/.config/git/attributes
。
core.hooksPath
默认情况下,Git 会在 _$GIT_DIR/hooks_
目录中查找你的钩子。将此设置为不同的路径时,例如 /etc/git/hooks ,Git 会尝试在该目录中找到你的钩子,例如 /etc/git/hooks/pre-receive 而不是 _$GIT_DIR/hooks/pre-receive_
。
路径可以是绝对路径也可以是相对路径。相对路径被视为相对于运行钩子的目录(参见 githooks [5] 的“DESCRIPTION”部分)。
如果您希望集中配置 Git 钩子而不是基于每个存储库配置它们,或者作为一个更加灵活和集中的替代方案来使用init.templateDir
来更改默认挂钩,则此配置变量很有用。
core.editor
当此值被设置时,并且未设置环境变量GIT_EDITOR
,在执行类似commit
和tag
等命令时,允许您通过启动编辑器编辑消息。见 git-var [1] 。
core.commentChar
在执行类似commit
和tag
等命令时,会在编辑消息的开头的添加设置的字符,并在编辑器退出后删除它们(默认 #)。
如果设置为“auto”,git-commit
将选择一个字符,该字符不是现有提交消息中任何行的开头字符。
core.filesRefLockTimeout
尝试锁定单个引用时重试的时间长度(以毫秒为单位)。值 0 表示根本不重试; -1 意味着无限期地尝试。默认值为 100(即重试 100 毫秒)。
core.packedRefsTimeout
尝试锁定packed-refs
文件时重试的时间长度(以毫秒为单位)。值 0 表示根本不重试; -1 意味着无限期地尝试。默认值为 1000(即重试 1 秒)。
core.pager
文本查看器供 Git 命令使用(例如, less )。该值应由 shell 解释。首选顺序是$GIT_PAGER
环境变量,然后是core.pager
配置,然后是$PAGER
,然后是在编译时选择的默认值(通常是 less)。
当未设置LESS
环境变量时,Git 将其设置为FRX
(如果设置了LESS
环境变量,Git 根本不会更改它)。如果您想有选择地覆盖LESS
的 Git 默认设置,您可以将core.pager
设置为例如less -S
。这将由 Git 传递给 shell,它将最终命令转换为LESS=FRX less -S
。环境不设置S
选项,但命令行会设置,指示较少截断长行。同样,将core.pager
设置为less -+F
将从命令行取消激活环境指定的F
选项,取消激活less
的“退出,如果一个屏幕”行为。可以专门为特定命令激活一些标志:例如,将pager.blame
设置为less -S
只能为git blame
启用行截断。
同样,当未设置LV
环境变量时,Git 将其设置为-c
。您可以通过将LV
导出为其他值或将core.pager
设置为lv +c
来覆盖此设置。
core.whitespace
要注意一系列以逗号分隔的常见空格问题。 git diff 将使用color.diff.whitespace
突出显示它们, git apply --whitespace = error 会将它们视为错误。您可以为-
添加前缀以禁用其中任何一个(例如-trailing-space
):
blank-at-eol
将行末尾的尾随空格视为错误(默认情况下启用)。space-before-tab
将在行的初始缩进部分中的制表符之前出现的空格字符视为错误(默认情况下启用)。indent-with-non-tab
将带有空格字符而不是等效选项卡缩进的行视为错误(默认情况下不启用)。tab-in-indent
将行的初始缩进部分中的制表符视为错误(默认情况下不启用)。blank-at-eof
将在文件末尾添加的空行视为错误(默认情况下启用)。trailing-space
是涵盖blank-at-eol
和blank-at-eof
的简写。cr-at-eol
将行尾处的回车处理作为行终止符的一部分,即使用它,如果此回车符之前的字符不是空格(默认情况下未启用),则trailing-space
不会触发。tabwidth=
告诉标签占用多少个字符位置;这与indent-with-non-tab
和 Git 修复tab-in-indent
错误有关。默认选项卡宽度为 8.允许的值为 1 到 63。
core.fsyncObjectFiles
在编写目标文件时,此布尔值将启用 fsync()。
这对于正确排序数据的文件系统来说是浪费时间和精力的,但对于不使用日志(传统 UNIX 文件系统)或仅使用日志元数据而不是文件内容(OS X 的 HFS+或 Linux)的文件系统非常有用。 ext3 带有“data = writeback”)。
core.preloadIndex
为 git diff 等操作启用并行索引预加载
这可以加速像 git diff 和 git status 这样的操作,特别是在像 NFS 这样具有弱缓存语义和相对较高的 IO 延迟的文件系统上。启用后,Git 将并行执行与文件系统数据的索引比较,从而允许重叠 IO。默认为 true。
core.unsetenvvars
仅限 Windows:以逗号分隔的环境变量名称列表,需要在生成任何其他进程之前取消设置。默认为PERL5LIB
,以说明 Git for Windows 坚持使用自己的 Perl 解释器。
core.createObject
您可以将其设置为 link ,在这种情况下,使用硬链接后删除源来确保对象创建不会覆盖现有对象。
在某些文件系统/操作系统组合上,这是不可靠的。将此配置设置为 rename;但是,这将删除检查,以确保不会覆盖现有的目标文件。
core.notesRef
显示提交消息时,还会显示存储在给定引用中的注释。ref 必须完全合格。如果给定的 ref 不存在,则不是错误,而是表示不应打印任何注释。
此设置默认为“refs/notes/commits”,它可以被GIT_NOTES_REF
环境变量覆盖。见 git-notes [1] 。
core.commitGraph
如果为 true,则 git 将读取 commit-graph 文件(如果存在)以解析提交的图形结构。默认为 false。有关详细信息,请参阅 git-commit-graph [1] 。
core.useReplaceRefs
如果设置为false
,则表现为在命令行上给出了--no-replace-objects
选项。有关详细信息,请参阅 git [1] 和 git-replace [1] 。
core.multiPackIndex
Git 中文参考(一)(5)https://developer.aliyun.com/article/1565874