什么是Git修订表达式？ [英] What is a Git Revision Expression?
问题描述
此外，它似乎在程序中的许多其他地方使用，所以我相信这一点很重要。
我在StackOverflow上找到了这个问题，但是这个人从来没有得到答案。
我只需要知道：什么是修订表达式？
git需要能够在许多常见操作中识别提交
有很多方法可以识别提交。您可以使用分支，标记，提交sha1或表达式。例如：
git log HEAD
HEAD 最终会解析为特定的提交，并且您将获得该日志。 YOu也可以这样说：
git log master
master 是一个分支，它也将解析为特定的提交。
git log fd72e9c99312
现在，提交。
以下文档就是您要查找的内容。取自 git-rev-parse 命令文档，位于 http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html 。
指定修订
修订参数通常（但不一定）命名提交对象。他们使用所谓的扩展SHA1语法。以下是拼写对象名称的各种方法。在列表结尾附近列出的名称将包含在提交中的树和blob。
$ b
完整的SHA1对象名称（40字节的十六进制字符串）或一个这样的子字符串在存储库中是唯一的。例如。 dae86e1950b1277e545cee180551750029cfe735和dae86e都命名相同的提交对象，如果你的仓库中没有其他对象的对象名称以dae86e开头的话。
git-describe;即最接近的标签，可选地后面跟着一个破折号和一些提交，后面跟着一个破折号，一个g和一个缩写的对象名称。
一个符号参考名称。例如。 master通常表示由$ GIT_DIR / refs / heads / master引用的提交对象。如果你碰巧有头/主人和标签/主人，你可以明确地说头/主告诉你的意思是哪一个。当含糊不清时，通过在以下规则中进行第一次匹配来消除a：
如果$ GIT_DIR / exists，那就是你的意思（这通常只对HEAD有用，FETCH_HEAD，ORIG_HEAD和MERGE_HEAD）;否则，$ GIT_DIR / refs / if exists;
否则，
否则，$ GIT_DIR / refs / heads / if exists;
$ GIT_DIR / refs / tags / if exists;否则，$ GIT_DIR / refs / remotes / if exists;
否则，$ GIT_DIR / refs / remotes // HEAD if exists。
HEAD将工作树中的更改命名为commit。 FETCH_HEAD用你最后的git-fetch调用记录你从一个远程仓库获取的分支。 ORIG_HEAD是通过命令创建的，这些命令以非常激烈的方式移动HEAD，在操作之前记录HEAD的位置，以便您可以轻松地将分支的顶端更改回到状态。当你运行git-merge时，MERGE_HEAD记录你正在合并到你的分支中的提交。
一个ref，后面加上后缀@ （例如{昨天}，{1个月2周3天1小时1秒前}或{1979-02-26 18:30:00}）来指定前一时间点的参考值。该后缀只能在ref名称后面立即使用，并且ref必须具有现有日志（$ GIT_DIR / logs /）。请注意，这会在给定的时间查看当地裁判的状态;例如，上周在您当地的主分支中有什么。如果你想查看在某些时候提交的提交信息，请参阅--since和--until。
后缀为@的后缀@ （例如{1}，{15}）来指定该ref的第n个先前值。例如，master @ {1}是master的直接前值，而master @ {5}是master的第5个前值。该后缀只能在ref名称后面立即使用，并且ref必须有一个现有日志（$ GIT_DIR / logs /）。
您可以使用带@空的参考部分获得当前分支的reflog。例如，如果您在分支blabla上，那么@ {1}的意思与blabla @ {1}相同。
特殊结构@ { - }表示在
后面加上一个后缀^表示该提交对象的第一个父对象。 ^表示第三父母（即，rev ^等于rev ^ 1）。作为一个特殊规则，rev ^ 0表示提交本身，当rev是引用提交对象的标记对象的对象名称时使用。
后缀〜到修订参数意味着作为指定提交对象的第四代祖父母的提交对象，仅在第一个父代之后。即rev〜3相当于rev ^^^，相当于rev ^ 1 ^ 1 ^ 1。请参阅下面的表格，了解这种形式的用法。
后缀^后面跟着括号内的对象类型名称（例如v0.99.8 ^ {commit}）意味着对象可以是一个标签，并递归地引用标签，直到找到该类型的对象，或者该对象不能被解除引用（在这种情况下，barf）。前面介绍的rev ^ 0是rev ^ {commit}的缩写。
后缀^后跟一个空括号对（例如v0.99.8 ^ {}）意味着对象可以是标签，并递归地引用标签，直到找到非标签对象。
冒号，后跟斜杠，后跟文本：这会命名提交消息以指定文本开始的提交。该名称返回可从任何ref访问的最年轻匹配提交。如果提交消息以！开头，则必须重复该操作;特殊序列：/！，接下来是别的！现在保留。
后缀：后跟路径;这个命名的Blob或树在给定路径中的树形对象由冒号前的部分命名。
一个冒号，后面跟着一个冒号（0到3）和一个冒号，然后是一条路径;这会在给定路径的索引中命名一个blob对象。缺少阶段号（以及后面的冒号）命名为阶段0条目。在合并期间，阶段1是共同祖先，阶段2是目标分支的版本（通常是当前分支），阶段3是来自被合并分支的版本。
< Jon Loeliger给出了一个例子。提交节点B和C都是提交节点A的父节点。父提交按从左到右的顺序排列。
GHIJ
\ / \ /
DEF
\ | / \
\ | / |
\ | / |
BC
\ /
\ /
A
A = = A ^ 0
B = A ^ = A ^ 1 = A〜1
C = A ^ 2 = A ^ 2
D = A ^^ = A ^ 1 ^ 1 = A〜2
E = B ^ 2 = A ^^ 2
F = B ^ 3 = A ^^ 3
G = A ^^^ = A ^ 1 ^ 1 ^ 1 = A〜3
H = D ^ 2 = B ^^ 2 = A ^^ ^ 2 = A〜2 ^ 2
I = F ^ = B ^ 3 ^ = A ^^ 3 ^
J = F ^ 2 = B ^ 3 ^ 2 = A ^^ 3 ^ 2
So, I am using Git GUI to make a repository. But I cant find ANY trace on Google, the Documentation, or anywhere else what a 'Revision Expression' is, and it is required to create a new Branch.
Also, it seems that this is used many other places in the program, so I belive it is important to know.
I did find a question on this on StackOverflow, but the guy never got an answer.
I just need to know: What is a Revision Expression?
git needs to be able to identify a commit during a number of common operations
There are a number of ways to identify a commit. You could use a branch, tag, commit sha1, or expressions. For example:
git log HEAD
HEAD eventually resolves to a specific commit, and you will be given the log for that. YOu could also say:
git log master
master is a branch, and that will also resolve to a specific commit.
git log fd72e9c99312
Now that IS the actual commit.
The below documentation is what you are looking for. Taken from the git-rev-parse command documentation at http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html.
SPECIFYING REVISIONS
A revision parameter typically, but not necessarily, names a commit object. They use what is called an extended SHA1 syntax. Here are various ways to spell object names. The ones listed near the end of this list are to name trees and blobs contained in a commit.
The full SHA1 object name (40-byte hexadecimal string), or a substring of such that is unique within the repository. E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both name the same commit object if there are no other object in your repository whose object name starts with dae86e.
An output from git-describe; i.e. a closest tag, optionally followed by a dash and a number of commits, followed by a dash, a g, and an abbreviated object name.
A symbolic ref name. E.g. master typically means the commit object referenced by $GIT_DIR/refs/heads/master. If you happen to have both heads/master and tags/master, you can explicitly say heads/master to tell git which one you mean. When ambiguous, a is disambiguated by taking the first match in the following rules:
if $GIT_DIR/ exists, that is what you mean (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD and MERGE_HEAD);
otherwise, $GIT_DIR/refs/ if exists;
otherwise, $GIT_DIR/refs/tags/ if exists;
otherwise, $GIT_DIR/refs/heads/ if exists;
otherwise, $GIT_DIR/refs/remotes/ if exists;
otherwise, $GIT_DIR/refs/remotes//HEAD if exists.
HEAD names the commit your changes in the working tree is based on. FETCH_HEAD records the branch you fetched from a remote repository with your last git-fetch invocation. ORIG_HEAD is created by commands that moves your HEAD in a drastic way, to record the position of the HEAD before their operation, so that you can change the tip of the branch back to the state before you ran them easily. MERGE_HEAD records the commit(s) you are merging into your branch when you run git-merge.
A ref followed by the suffix @ with a date specification enclosed in a brace pair (e.g. {yesterday}, {1 month 2 weeks 3 days 1 hour 1 second ago} or {1979-02-26 18:30:00}) to specify the value of the ref at a prior point in time. This suffix may only be used immediately following a ref name and the ref must have an existing log ($GIT_DIR/logs/). Note that this looks up the state of your local ref at a given time; e.g., what was in your local master branch last week. If you want to look at commits made during certain times, see --since and --until.
A ref followed by the suffix @ with an ordinal specification enclosed in a brace pair (e.g. {1}, {15}) to specify the n-th prior value of that ref. For example master@{1} is the immediate prior value of master while master@{5} is the 5th prior value of master. This suffix may only be used immediately following a ref name and the ref must have an existing log ($GIT_DIR/logs/).
You can use the @ construct with an empty ref part to get at a reflog of the current branch. For example, if you are on the branch blabla, then @{1} means the same as blabla@{1}.
The special construct @{-} means the th branch checked out before the current one.
A suffix ^ to a revision parameter means the first parent of that commit object. ^ means the th parent (i.e. rev^ is equivalent to rev^1). As a special rule, rev^0 means the commit itself and is used when rev is the object name of a tag object that refers to a commit object.
A suffix ~ to a revision parameter means the commit object that is the th generation grand-parent of the named commit object, following only the first parent. I.e. rev~3 is equivalent to rev^^^ which is equivalent to rev^1^1^1. See below for a illustration of the usage of this form.
A suffix ^ followed by an object type name enclosed in brace pair (e.g. v0.99.8^{commit}) means the object could be a tag, and dereference the tag recursively until an object of that type is found or the object cannot be dereferenced anymore (in which case, barf). rev^0 introduced earlier is a short-hand for rev^{commit}.
A suffix ^ followed by an empty brace pair (e.g. v0.99.8^{}) means the object could be a tag, and dereference the tag recursively until a non-tag object is found.
A colon, followed by a slash, followed by a text: this names a commit whose commit message starts with the specified text. This name returns the youngest matching commit which is reachable from any ref. If the commit message starts with a !, you have to repeat that; the special sequence :/!, followed by something else than ! is reserved for now.
A suffix : followed by a path; this names the blob or tree at the given path in the tree-ish object named by the part before the colon.
A colon, optionally followed by a stage number (0 to 3) and a colon, followed by a path; this names a blob object in the index at the given path. Missing stage number (and the colon that follows it) names a stage 0 entry. During a merge, stage 1 is the common ancestor, stage 2 is the target branch's version (typically the current branch), and stage 3 is the version from the branch being merged.
Here is an illustration, by Jon Loeliger. Both commit nodes B and C are parents of commit node A. Parent commits are ordered left-to-right.
G H I J
\ / \ /
D E F
\ | / \
\ | / |
\|/ |
B C
\ /
\ /
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2 = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
这篇关于什么是Git修订表达式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
