目录 搜索
Guides gitattributes giteveryday gitglossary gitignore gitmodules gitrevisions gittutorial gitworkflows Administration git archive git bundle git clean git filter-branch git fsck git gc git instaweb git reflog Basic Snapshotting git add git commit git diff git mv git reset git rm git status Branching and Merging git branch git checkout git log git merge git mergetool git stash git tag Debugging git bisect git blame git grep Email git am git format-patch git request-pull git send-email External Systems git fast-import git svn Getting and Creating Projects git clone git init Git git annotate git archimport git bisect-lk2009 git check-attr git check-mailmap git check-ref-format git checkout-index git cherry git citool git column git credential git credential-cache git credential-store git cvsexportcommit git cvsimport git cvsserver git diff-files git diff-tree git difftool git fast-export git fetch-pack git fmt-merge-msg git get-tar-commit-id git gui git http-backend git http-fetch git http-push git imap-send git index-pack git interpret-trailers git ls-remote git ls-tree git mailinfo git mailsplit git merge-file git merge-index git merge-one-file git merge-tree git mktag git mktree git name-rev git notes git p4 git pack-objects git pack-redundant git pack-refs git parse-remote git patch-id git prune git prune-packed git quiltimport git receive-pack git remote-ext git remote-fd git remote-testgit git repack git replace git rerere git send-pack git sh-i18n git sh-setup git shell git show-branch git show-index git stripspace git unpack-file git unpack-objects git upload-archive git upload-pack git var git verify-commit git verify-tag git whatchanged git worktree Inspection and Comparison git describe git shortlog git show Miscellaneous api credentials api index gitcli gitcore tutorial gitcredentials gitcvs migration gitdiffcore githooks gitk gitnamespaces gitremote helpers gitrepository layout gitsubmodules gittutorial 2 gitweb gitweb.conf pack format User Manual Patching git apply git cherry-pick git rebase git revert Plumbing Commands git cat-file git check-ignore git commit-tree git count-objects git diff-index git for-each-ref git hash-object git ls-files git merge-base git read-tree git rev-list git rev-parse git show-ref git symbolic-ref git update-index git update-ref git verify-pack git write-tree Server Admin git daemon git update-server-info Setup and Config git git config git help Sharing and Updating Projects git fetch git pull git push git remote git submodule
文字

命名

git-rev-parse - Pick out and massage parameters

概要

git rev-parse [ --option ] <args>…

描述

许多Git瓷器命令会混合使用标志(即以短划线开头的参数-)以及参数,这些参数用于git rev-list它们在内部使用的基础命令,以及标志和参数用于其下游使用的其他命令git rev-list。该命令用于区分它们。

选项

操作模式

这些选项中的每一个都必须首先出现在命令行中。

--parseopt

使用git rev-parse在选项解析模式(见下文PARSEOPT部分)。

--sq-quote

使用git rev-parse的shell引用模式(见下面的SQ-报价部分)。与--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>

如果没有用户给出的参数,则<arg>改为使用。

--prefix <arg>

行为就像git rev-parse<arg>工作树的子目录中调用一样。任何相关的文件名被解析,就好像它们以前缀一样,<arg>并将以该形式打印。

这可用于将参数转换为在子目录中运行的命令,以便在移动到存储库的顶层后仍可使用它们。例如:

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命名为提交ish的现有对象(即,提交或指向提交的带注释的标记)。确保可以使用$VAR任何类型的现有对象的名称git rev-parse "$VAR^{object}"

-q   --quiet

只在--verify模式中有意义。如果第一个参数不是有效的对象名称,则不输出错误消息; 而是静静地退出非零状态。成功时,将有效对象名称的SHA-1打印到stdout。

--sq

通常每个标志和参数输出一行。此选项使输出成为单行,并且适用于shell的消耗。当你期望你的参数包含空格和换行符时(例如使用镐-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类似,但它省略了不是参考的输入(即分支或标签名称;或者更明确地消除“头部/主”形式的歧义,当您想命名“主”分支时,标签“master”),并将其显示为完整的refnames(例如“refs / heads / master”)。

对象的选项

--all

显示在中找到的所有参考refs/

--branches=pattern   --tags=pattern   --remotes=pattern

显示所有分支,标签,或远程跟踪分支,分别为(即,裁判发现refs/headsrefs/tagsrefs/remotes分别)。

如果pattern给出a,则只显示匹配给定shell glob的引用。如果模式不包含匹配字符(?,,*[),则通过追加将其转换为前缀匹配/*

--glob=pattern

显示与shell glob模式匹配的所有参考pattern。如果模式没有开始refs/,则会自动添加前缀。如果模式不包含匹配字符(?,,*[),则通过追加将其转换为前缀匹配/*

--exclude=<glob-pattern>

不包括裁判匹配<glob-pattern>,未来--all--branches--tags--remotes,或--glob原本考虑。这个选项排除累积模式到下一个的重复--all--branches--tags--remotes,或--glob选择(其他选项或参数不清除积累的模式)。

给予不应该开始的模式refs/headsrefs/tagsrefs/remotes当应用到--branches--tags--remotes分别,他们必须开始refs/在应用于--glob--all。如果尾随/*是有意的,则必须明确给出。

--disambiguate=<prefix>

显示名称以给定前缀开头的每个对象。<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

当存储库是裸打印“真”,否则“假”。

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

解析日期字符串,并输出相应的--max-age =参数git rev-list

--until=datestring   --before=datestring

解析日期字符串,并输出相应的--min-age =参数git rev-list

<args>…

要解析的标志和参数。

指定修订

修订参数<rev>通常(但不一定)命名提交对象。它使用所谓的extended SHA-1语法。以下是拼写对象名称的各种方法。列表附近列出的名称包含在提交中的树和blob。

<sha1>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e

完整的SHA-1对象名称(40字节的十六进制字符串)或存储库中唯一的前导子字符串。例如,dae86e1950b1277e545cee180551750029cfe735和dae86e都会命名相同的提交对象,前提是存储库中没有其他对象,其对象名称以dae86e开头。

<describeOutput>, e.g. v1.7.4.2-679-g3bee7fb

输出来自git describe; 即最接近的标记,可选地后跟破折号和多个提交,后跟短划线,a g和缩写对象名称。

<refname>, e.g. master, heads/master, refs/heads/master

符号参考名称。例如master通常意味着引用的提交对象refs/heads/master。如果你碰巧有两个heads/mastertags/master,你可以明确地说heads/master要告诉Git的你的意思是哪一个。当模棱两可时,<refname>通过在以下规则中进行第一次匹配来消除a :

  1. 如果$GIT_DIR/<refname>存在,那就是你的意思(这通常是有用的,只有为HEADFETCH_HEADORIG_HEADMERGE_HEADCHERRY_PICK_HEAD);

  1. 否则,refs/<refname>如果存在;

  1. 否则,refs/tags/<refname>如果存在;

  1. 否则,refs/heads/<refname>如果存在;

  1. 否则,refs/remotes/<refname>如果存在;

  1. 否则,refs/remotes/<refname>/HEAD如果存在。

HEAD命名您在工作树中基于更改的提交。FETCH_HEAD记录您在上次git fetch调用时从远程存储库中获取的分支。ORIG_HEAD是通过命令创建的,这些命令HEAD以激烈的方式移动您的行为,记录HEAD它们在操作之前的位置,以便您可以轻松地将分支的顶端更改回到运行之前的状态。MERGE_HEAD记录您在运行时正在合并到您的分支中的提交git mergeCHERRY_PICK_HEAD记录您在运行时正在挑选的提交git cherry-pick

请注意,refs/*上述任何情况都可能来自$GIT_DIR/refs目录或$GIT_DIR/packed-refs文件。虽然未指定ref名称编码,但首选UTF-8,因为某些输出处理可能采用UTF-8中的ref名称。

@

@ alone is a shortcut for HEAD.

<refname>@{<date>}, e.g. master@{yesterday}, HEAD@{5 minutes ago}

后面跟着@带括号的括号中的后缀(例如{yesterday}{1 month 2 weeks 3 days 1 hour 1 second ago}{1979-02-26 18:30:00})的后缀指定前一个时间点的ref的值。该后缀只能在ref名称后面使用,并且ref必须具有现有的日志($GIT_DIR/logs/<ref>)。请注意,这会在给定的时间查看当地裁判的状态; 例如master上周您当地的分支机构。如果您想查看某些时间内提交的内容,请参阅--since--until

<refname>@{<n>}, e.g. master@{1}

后缀为@带括号的后缀(例如{1}{15})指定了该ref的第n个前置值。例如master@{1}masterwhile master@{5}是第5个先前值的即时先验值master。该后缀只能在ref名称后面使用,并且ref必须具有现有的日志($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(简称<branchname>@{u})的后缀是指由branchname指定的分支设置为在(使用branch.<name>.remoteand branch.<name>.merge)配置的基础上构建的分支。缺少的branchname默认为当前的。当用大写拼写时,这些后缀也是可接受的,无论大小写是什么,它们都表示相同的事物。

<branchname>@{push}, e.g. master@{push}, @{push}

@{push}如果在检出时git push运行branchname(或当前HEAD没有指定branchname),后缀将报告分支“我们将推送到哪里” 。由于我们的推送目标位于远程存储库中,当然,我们会报告与该分支对应的本地跟踪分支(即,某处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^0

^修订参数的后缀表示该提交对象的第一个父代。^<n>意味着第n个父母(即<rev>^相当于<rev>^1)。作为一个特殊规则,<rev>^0意味着提交本身,并在<rev>引用提交对象的标记对象的对象名称时使用。

<rev>~<n>, e.g. master~3

~<n>修订参数的后缀表示作为指定提交对象的第n代祖先的提交对象,仅在第一个父代之后。即<rev>~3相当于<rev>^^^哪个相当于<rev>^1^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 nasty bug下面的语法不同之处在于它返回最年轻的匹配提交其是从可到达<rev>之前^

:/<text>, e.g. :/fix nasty bug

一个冒号,后跟一个斜线,后跟一个文本,命名提交消息与指定正则表达式匹配的提交。该名称返回可从任何ref访问的最年轻匹配提交。正则表达式可以匹配提交消息的任何部分。要匹配以字符串开头的消息,可以使用例如:/^foo。特殊序列:/!保留给修饰符以匹配内容。:/!-foo执行否定匹配,同时:/!!foo匹配文字!字符,然后匹配foo。任何以其他序列开始的序列:/!现在都被保留。

<rev>:<path>, e.g. HEAD:README, :README, master:./README

一个后缀:后面跟着一个路径的名称是由冒号前部分命名的tree-ish对象中给定路径上的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^0B = A^   = A^1     = A~1C = A^2  = A^2D = A^^  = A^1^1   = A~2E = B^2  = A^^2F = B^3  = A^^3G = A^^^ = A^1^1^1 = A~3H = D^2  = B^^2    = A^^^2  = A~2^2I = F^   = B^3^    = A^^3^J = F^2  = B^3^2   = A^^3^2

指定范围

历史遍历命令,例如git log对一组提交进行操作,而不仅仅是一次提交。

对于这些命令,使用上一节中描述的符号来指定单个修订,意味着reachable来自给定提交的一组提交。

提交的可达集是提交本身和祖先链中的提交。

提交排除

^<rev> (caret) Notation

要排除提交可达的提交,使用前缀^符号。例如,^r1 r2意味着提交可达,r2但不包括从r1(即r1其祖先)可达的。

虚线表示法

The .. (two-dot) Range Notation

^r1 r2组操作似乎经常有它的简写。当你有两个提交r1并且r2(根据上面指定版本中所述的语法命名)时,你可以要求提交从r2到达的提交,但不包括从r1到达的那些提交,^r1 r2它可以写为r1..r2

The (three dot) Symmetric Difference Notation

类似的符号r1...r2被称为和的对称差,r1并被r2定义为r1 r2 --not $(git merge-base --all r1 r2)。它是从r1(左侧)或r2(右侧)中的任一个可达的提交集合,但不是来自两者。

在这两个简写符号中,可以省略一端,并将其默认为HEAD。例如,origin..是一个简写,origin..HEAD并问“自从我从原始分支分出后,我做了什么?” 同样,它..origin也是一种速记,HEAD..origin并问道:“我从他们身上分离出来后,起源究竟发生了什么?” 请注意,..这意味着HEAD..HEAD哪个空白区域可以从HEAD到达和无法到达。

Other <rev>^ Parent Shorthand Notations

还有三个其他的shorthands,对于合并提交,对于由提交和它的父提交形成的集合进行命名特别有用。

r1^@符号表示的所有家长r1

r1^!表示包括提交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^@

一个后缀^后跟一个符号与列出所有父母的<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^1 B              E I J F B
C^@    = C^1= F                   I J F
B^@    = B^1 B^2 B^3= D E F               D G H E F I J
C^!    = C ^C^@= C ^C^1= C ^F                C
B^!    = B ^B^@= B ^B^1 ^B^2 ^B^3= B ^D ^E ^F          B
F^! D  = F ^I ^J D           G H D F

Parseopt

--parseopt模式下,git rev-parse帮助按摩选项,使shell脚本拥有与C builtins相同的设施。它作为一个选项标准化器(例如拆分单个交换机聚合值),有点像getopt(1)

它接受标准输入的解析和理解选项的规范,并在标准输出上回显一个适合于sh(1) eval用规范化参数替换参数的字符串。如果发生错误,它会在标准错误流上输出使用情况,并以代码129退出。

注意:确保在传递结果时引用结果eval。见下面的例子。

输入格式

git rev-parse --parseopt输入格式完全基于文本。它有两部分,由仅包含一行的行分隔--。分隔符之前的行(应该是一个或多个)用于使用。分隔符后面的行描述了选项。

每行选项都有以下格式:

<opt-spec><flags>*<arg-hint>? SP+ help LF

<opt-spec>

它的格式是短选项字符,然后是用逗号分隔的长选项名称。这两个部分都不是必需的,但至少需要一个。可能不包含任何<flags>字符。h,helpdry-run并且f是正确的例子<opt-spec>

<flags>

<flags> are of *, =, ? or !.

  • 如果选项带有参数,请使用=

  • 使用?意味着选项接受一个可选参数。您可能想要使用该--stuck-long模式来明确地解析可选参数。

  • 使用*意味着该选项不应该在所生成的使用上市-h的说法。它显示为--help-all在gitcli [7]中记录。

  • 使用!不使提供相应的否定长选项。

<arg-hint>

<arg-hint>,如果指定,则用作帮助输出中参数的名称,用于带有参数的选项。<arg-hint>由第一个空格终止。通常使用短划线来分隔多词论证提示中的单词。

在删除空格之后,该行的其余部分将用作与该选项关联的帮助。

空白行被忽略,并且不符合此规格的行被用作选项组标题(用空格开始行以有意地创建此类行)。

例子

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-报价

--sq-quote模式中,git rev-parse标准输出上的回声适合单线sh(1) eval。这条线是通过标准化后面的参数来完成的--sq-quote。除了引用参数外,没有其他任何事情完成了。

如果希望命令输入git rev-parse在输出被shell引用之前仍照常解释,请参阅--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为空,则会打印来自主服务器的提交对象名称。

上一篇: 下一篇: