`在git的注释标签中输入`commit` [英] `type commit` in an annotated tag in git

问题描述

在git中用 git cat-file -p< hash-of-tag> 回显一个带注释的标签会产生如下所示的结果：

  object< sha1-hash> 
类型提交
标记0.0.1 
 tagger My Name（...）
 
标记
  

object 指向我的情况下的提交对象。 类型提交意味着这不一定是这种情况。是否有注释标记不指向提交的情况？

解决方案

是：注释标记对象可以指向另一个注释标记对象，甚至直接指向树或blob。这些都是相当少见的。

git rev-parse 命令 - rev-parse 就是面向用户的例程接口 - 具有剥离标签或甚至提交的概念，以达到特定的目标对象类型。例如，如果要查看附加到提交或标记或哈希ID的树：

git rev-parse whatever ^ {tree}

会将 变成 不管 是一个带注释的标签，它会重复跟随标签到它的对象，直到它到达一个非标签，提交，树或blob：



• 如果我们到了树，我们就完成了。


• 如果我们已经达到提交，每个提交都有一个顶级树，所以我们提取该提交的树。


• 如果我们已经达到了一个blob，就没有树，所以命令（无论是 git rev-parse 或者例如 git diff 或<$
  
  
  

  命令如 git diff-tree 需要一个< tree-ish> 自动将你给它们的任何参数变成树，就好像你添加了 ^ {tree} 后缀。正如您所预料的那样，还有 ^ {commit} 和 ^ {blob} 后缀。还有一个 ^ {tag} 后缀，它只是验证某个东西确实是一个标签（因为没有其他对象类型可以解析为 a标签），并且有一个 ^ {} 后缀，意思是将标签解析为其对象，即剥离所有带注释的标签，然后获取任何剩余的对象。 / p>
  
  

  完整的规则在 gitrevisions文档。请注意，并非每个Git命令的行为都如前所述：特别是，在遵循gitrevisions中的六步过程之前， git checkout 会尝试将其参数视为分支名称。这意味着如果名称 foo 既可以是标签和，也可以是 git checkout foo 找到分支（即检出 refs / heads / foo ），但 git show foo 显示解析标签的结果。

  
  

  Echoing an annotated tag in git with git cat-file -p <hash-of-tag> produces something like this:

  object <sha1-hash>
  type commit
  tag 0.0.1
  tagger My Name (...)
  
  Description of tag
  

  object points to a commit object in my case. type commit implies this mustn't be the case necessarily. Are there cases where annotated tags don't point to commits?

  解决方案

  Yes: an annotated tag object can point to another annotated tag object, or even directly to a tree or blob. These are all fairly rare though.

  The git rev-parse command—really, Git in general; rev-parse is just the user oriented interface to the routines—has the notion of "peeling" a tag, or even a commit, to reach a particular target object type. For instance, if you want to view the tree attached to a commit or tag or hash ID:

  git rev-parse whatever^{tree}

  turns the whatever part into whatever it is, then attempts to "drill down" to the point where we get a tree object. If whatever is an annotated tag, this follows the tag to its object, repeatedly, until it arrives at a non-tag, which by definition is either a commit, tree, or blob:

  • If we've reached a tree, we are done.
  • If we've reached a commit, each commit has one top-level tree, so we extract that commit's tree.
  • If we've reached a blob, there is no tree to be found, so the command (whether that's git rev-parse or, e.g., git diff or git diff-tree) errors out.

  Commands like git diff-tree that want a <tree-ish> automatically turn whatever argument you give them into the tree, as if you had added the ^{tree} suffix. As you might expect, there are also ^{commit} and ^{blob} suffixes. There is also a ^{tag} suffix, which simply verifies that something is indeed a tag (since no other object type can be resolved to a tag), and there is a ^{} suffix that means "resolve a tag to its object", i.e., peel off all annotated tags, then get whatever object remains.

  The full rules are described in the gitrevisions documentation. Note that not every Git command behaves as described: in particular, git checkout tries to treat its argument as a branch name before following the six-step process in gitrevisions. This means that if the name foo can be both a tag and a branch, git checkout foo finds the branch (i.e., checks out refs/heads/foo), but git show foo shows the result of resolving the tag.

  这篇关于`在git的注释标签中输入`commit`的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！