git - 如何在 2.27+ 中使用 git sparse-checkout

Question

我试图从以下几个教程步骤中重现:

https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout

这是为 git 2.25 制作的，但现在在 2.27 中，运行时什么也没有发生:

$ git sparse-checkout set client/android

我找不到让它工作的方法。

这是一个 MWE:

$ git clone --no-checkout https://github.com/derrickstolee/sparse-checkout-example
Cloning into 'sparse-checkout-example'...

$ cd sparse-checkout-example/

$ git sparse-checkout init --cone

使用 git 2.25，我获得了一个非空目录:

$ ls -a
.  .. bootstrap.sh LICENSE.md  README.md .git

使用 git 2.27，我获得了一个空目录:

$ ls -a
.  .. .git

Answer 1

我相信我找到了原因。提交 f56f31af0301 到 Git 更改了 sparse-checkout 的实现所以，当你有一个未初始化的工作树时(就像你在运行 git clone --no-checkout 之后一样)，运行 git sparse-checkout init不会将任何文件 check out 到您的工作树中。在以前的版本中，该命令实际上会 check out 文件，这可能会产生意想不到的效果，因为此时您没有事件分支。

相关提交，f56f31af0301已包含在 Git 2.27 中，但未包含在 2.25 中。这解释了为什么您看到的行为不是您试图遵循的网页上显示的行为。基本上，网页上的行为是一个错误，当时没有人意识到这是一个错误，但在 Git 2.27 中，它已被修复。

我认为，这在提交 b5bfc08a972d 的消息中得到了很好的解释。 :

So...that brings us to the special case: a git clone performed with --no-checkout. As per the meaning of the flag, --no-checkout does not check out any branch, with the implication that you aren't on one and need to switch to one after the clone. Implementationally, HEAD is still set (so in some sense you are partially on a branch), but

• the index is "unborn" (non-existent)
• there are no files in the working tree (other than .git/)
• the next time git switch (or git checkout) is run it will run unpack_trees with initial_checkout flag set to true.

It is not until you run, e.g. git switch <somebranch> that the index will be written and files in the working tree populated.

With this special --no-checkout case, the traditional read-tree -mu HEAD behavior would have done the equivalent of acting like checkout -- switch to the default branch (HEAD), write out an index that matches HEAD, and update the working tree to match. This special case slipped through the avoid-making-changes checks in the original sparse-checkout command and thus continued there.

After update_sparsity() was introduced and used (see commit f56f31a ("sparse-checkout: use new update_sparsity() function", 2020-03-27)), the behavior for the --no-checkout case changed: Due to git's auto-vivification of an empty in-memory index (see do_read_index() and note that must_exist is false), and due to sparse-checkout's update_working_directory() code to always write out the index after it was done, we got a new bug. That made it so that sparse-checkout would switch the repository from a clone with an "unborn" index (i.e. still needing an initial_checkout), to one that had a recorded index with no entries. Thus, instead of all the files appearing deleted in git status being known to git as a special artifact of not yet being on a branch, our recording of an empty index made it suddenly look to git as though it was definitely on a branch with ALL files staged for deletion! A subsequent checkout or switch then had to contend with the fact that it wasn't on an initial_checkout but had a bunch of staged deletions.