读取树命令用法的基本示例 [英] a basic example of the read-tree command usage

问题描述

我在重命名时遇到了问题一个文件，并得到了一个包含两个git命令的解决方案 - git read-tree -i HEAD 和 git checkout-index -a -f 。我似乎已经弄清楚第二个人做了什么并进行了测试，但我无法理解为什么即使是最简单的情况我也需要第一个人。我认为它可能取代 git add 命令，并添加一个文件到索引，但是当我创建一个新文件并运行命令，然后检查索引的内容 ls-files --staged 它没有将这些文件显示为已添加，所以可能我对命令目的的假设是错误的。我还访问了手册页面，但仍不明白为什么我需要该命令。

1. 解析传递给它的tree-ish，以查找存在于描述树的Git存储库中的对象。

   
   
   

   一棵树代表Git中的一个目录：这种类型的对象列出了构成树的blob（文件）和嵌套目录的嵌套树的SHA-1和文件系统名称。每个提交都只引用一棵树，它代表顶级项目目录本身的状态。

   
   
   

   tree-ish是Git能够解析的规范到树对象的名称。例如， HEAD 首先被解析为一个引用的名称，然后它指向的分支被追赶以获得其提示提交，然后解析它以获取其名称tree对象。
   

2. 以递归方式读取获取的树对象，并使用这些对象的信息填充索引。索引不包含文件的实际数据 - 仅包含元数据信息。

   
   
   

   IOW，索引就像一个保存在单个文件中的微型文件系统。它的格式经过优化，可以通过一个巨大的嵌套文件集超快访问。

现在另一个命令<$可以使用c $ c> git checkout-index 使工作树与索引同步。像 git checkout< commit> 这样的命令完成以下工作：调用 git read-tree 来填充索引，然后 git checkout-index 来同步工作树。




这就是基础知识。该命令可以做的比这更多：






• 如果通过 -m 命令行选项，它可以将传递给它的树合并到索引中。
  
• 它能够以某种方式读取指定的树，以便它的文件出现（在索引中）在项目的子目录中（通过 - 前缀）。


• 它能清空索引（通过<$ c $






当我们用最简单的形式调用它时一直在处理你原来的问题，它只是用目前 HEAD 引用的内容替换索引的内容。





请注意， git read-tree 是一个管道命令，不打算由用户常规使用。当你执行 git checkout< commit> 时，它会自动调用。我建议直接调用它，因为谁知道如果运行 git checkout HEAD 会真正更新您的索引，否则它会决定反正 HEAD 的状态应该完成。手动调用确保指数开始包含我们所需的状态。在一般情况下，你不需要这个程序，因此这就是为什么很难提出一个简单的使用示例。




I was having an issue with renaming a file and was given a solution which included two git commands - git read-tree -i HEAD and git checkout-index -a -f. I seems to have figured out what the second one does and tested it, but I can't grasp why I would need the first one even for the simplest case. I thought that it somehow could substitue git add command and add a file to index, however when I created a new file and run the command and then checked the contents of index with ls-files --staged it didn't show this files as added, so probably my assumption about the purpose of the command is wrong. I also visited the manual page but still don't understand why I would need that command.

解决方案

git read-tree goes like this:

1. Parses a "tree-ish" passed to it to find an object existing in the Git repository describing a tree.

   A tree is what represents a directory in Git: this kind of object lists the SHA-1 and filesystem names of blobs (files) and nested trees (of nested directories) comprising the tree. Each commit references exactly one tree which represents the state of the top-level project directory itself.

   A "tree-ish" is a specification whish Git is able to parse down to the name of a tree object. For instance, HEAD is first parsed as the name of a reference, then the branch it points to is chased to get its tip commit, then it's parsed to get the name of its tree object.

2. Reads the acquired tree object, recursively, and populates the index with the information on these objects. The index does not contain the actual data of the files—only meta information on them.

   IOW, the index is like a miniature filesystem kept in a single file. Its format is optimized for super-fast access over a huge nested sets of files.

Now another command, git checkout-index can be used to bring the work tree in sync with the index. Commands like git checkout <commit> do exactly this: call git read-tree to populate the index and then git checkout-index to sync the work tree with it.

That's the basics. The command is able to do more than that:

• If passed the -m command line option, it's able to merge the tree(s) passed to it into the index.
• It's able to read the indicated tree in a way so that its files appear (in the index) in a subdirectory of the project (via --prefix).
• It's able to empty the index (via --empty).

In the simplest form we've called it when we've been dealing with your original problem, it just replaced the contents of the index with what was referenced by HEAD at the moment.

Note that git read-tree is a plumbing command, not intended to be routinely used by users. It's called automatically when you do things like git checkout <commit>. I've advised to call it directly because who knows if running git checkout HEAD would really update your index or it would decide that since it anyway reflects the state of the HEAD nothing should be done. Calling it by hand ensured the index started to contain exactly the state we needed. In the general case you don't need this program and hence that's why it's hard to come up with a trivial usage example.

这篇关于读取树命令用法的基本示例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！