Git 工作树：两个工作树指向同一个位置，不能被修剪

Question

当我这样做时git worktree list，它显示如下。

/path/to/workspace  c943d35 [master]
/path/to/workspace  ef4df56 (detached HEAD)

这是我的工作目录（不是工作树目录）。我不知道它是怎么发生的，以及如何清洁它。我试过了git worktree prune，但它不会改变任何东西。任何帮助将不胜感激。非常感谢。

Answer 1

git worktree——细节提到：

每个链接的工作树在存储库目录中都有一个私有子目录$GIT_DIR/worktrees。

检查您的内容，main repo/.git/worktrees看看是否有可以手动删除的子文件夹。

Git 2.20（2018 年第 4 季度）修复了一个错误，如果路径丢失（例如，手动删除），可以在多个工作树条目下注册相同的路径。
此外，为方便起见，扩大--force适用的案例数量。

请参阅Jeff King ( ) 的提交 684e742（2018 年 8 月 30 日）。 见提交3a54043，提交f414310，提交68a6b3a，提交e19831c，提交cb56f55，提交45059e6，提交602aaed，提交e5353be，提交4c5fa9e通过（2018年8月28日），埃里克·阳光（）。^{（由Junio C Hamano合并-- --在commit 1c515bf，2018 年 9 月 17 日）}peff
sunshineco
gitster

worktree:.git/worktrees如果在“ remove”之后为空，则删除

为了清洁，如果修剪完成后目录为空，“ git worktree prune”将删除该.git/worktrees目录。

为了一致性，如果git worktree remove <path>删除.git/worktrees后为空，同样将“ ”删除。

同样的 Git 2.20，在遍历对象以获得可达性并决定哪些对象是不可引用的和可消耗的时，也被教导要考虑其他工作树的每个工作树引用作为起点，以防止数据丢失。

见提交14f74d5（2018年11月3日），提交c9ef0d9，提交b29759d，提交ab3e1f7，提交061e420，提交3a3b9d8（2018年10月21日），并提交8aff1a9，提交5c79f74（2018年9月29日）通过Nguy 2 N泰伍2 C维战（pclouds)。
请参阅以利亚纽伦 ( )提交的 a8c754d (2018 年 10 月 21 日)。^{（由Junio C Hamano合并-- --在提交 e146cc9，2018 年 11 月 13 日）}newren
gitster

特别是（commit 3a3b9d8）：

refs：新的 ref 类型使每个工作树的 ref 对所有工作树可见

多工作树的问题之一是从另一个工作树访问一个工作树的每个工作树引用。
这是通过多个引用存储解决的，其中代码可以打开另一个工作树的引用存储并可以访问该工作树的引用空间。

这样做的问题是报告。
“ HEAD”在另一个参考空间中也被称为“HEAD”，就像在当前参考空间中一样。
为了区分它们，所有代码都必须以某种方式携带引用存储并打印类似“ HEAD from this ref store”的内容。

我们没有输入单独的引用空间，而是使来自其他工作树的引用在当前引用空间中可用。
所以“ HEAD”总是当前工作树的 HEAD，但是我们可以用“ worktrees/blah/HEAD”来表示来自名为“ blah”的工作树的 HEAD 。
这种语法恰好与底层目录结构相匹配，这使得实现更容易一些。

必须特别对待主工作树，因为好吧……它从一开始就很特别。
所以主工作树的 HEAD 可以通过名称“ main-worktree/HEAD”而不是“ worktrees/main/HEAD”访问，因为“ main”可能只是另一个辅助工作树。

此补丁还可以从另一个工作树中的一个工作树中指定引用，例如

git log worktrees/foo/HEAD

那（新的引用“ worktrees/<name>/HEAD”）导致 Git 2.23（2019 年第 2 季度），其中的代码现在会清理给工作树的名称，以确保这些引用格式正确。

参见Nguy?n Thái Ng?c Duy ( ) 的commit 1de16ae (08 Mar 2019 )。 帮助者：杰夫·金 ( )。^{（由Junio C Hamano合并-- --在commit 0d107b1，2019 年 6 月 13 日）}pclouds
peff
gitster

worktree add：清理工作树名称

工作树名称基于$(basename $GIT_WORK_TREE).
直到3a3b9d8（refs：新的 ref 类型使每个工作树的 ref 对所有工作树可见 - 2018-10-21，Git v2.20.0-rc0）才有意义，其中工作树名称可以是 refname 的一部分，并且必须跟在 refname 之后规则。

更新 ' worktree add' 代码以删除特殊字符以遵循这些规则。将来，如果用户对这种愚蠢的字符替换不满意，他们将能够自己指定工作树名称。

并且同一个 Git 2.22.1（2019 年第三季度）提到“ git worktree add”曾经在连接到同一存储库的另一个工作树损坏时失败，这已得到纠正。

请参阅Nguy?n Thái Ng?c Duy ( ) 的commit 105df73（2019 年 5 月 13 日）。^{（由Junio C Hamano合并-- --在提交 933f294 中，2019 年 7 月 25 日）}pclouds
gitster

worktree add: 容忍腐败的工作树

find_worktree()可能会意外死亡（），因为它使用real_path() 而不是更温和的版本。

当它在 'git worktree add' 中使用时（在cb56f55 中添加（worktree：不允许多次添加相同的路径，2018-08-28，Git v2.20.0-rc0），或从 v2.20.0 开始。虽然真正的错误find_worktree()要早得多) 并且有一个糟糕的工作树，这die()可能会阻止人们添加新的工作树。

触发此操作的“不良”条件是删除工作树位置的父级。然后real_path()会抱怨。

使用另一个版本，这样坏的工作树就不会影响“ worktree add”。
坏的最终会被修剪，我们只需要容忍它们一点。

在 Git 2.26（2020 年第一季度）之前，在极少数情况下，“ ”可能认为它已经是注册的工作树，即使它不是，并拒绝添加新的工作树。 这已得到纠正。git worktree add <path><path>

请参阅Eric Sunshine ( ) 的提交 bb69b3b、bb4995f、a80c4c2 (2020 年 2 月 24 日)。^{（由Junio C Hamano合并-- --在2020 年 3 月 5 日提交 49e5043 中）}sunshineco
gitster

worktree: 不允许“ add”验证被后缀匹配所欺骗

^{报告人：Cameron Gunnin
签字人：Eric Sunshine}

“ ”在批准为新工作树的有效位置之前执行各种检查。git worktree add <path><path>

除了确保<path>不存在之外，它询问的问题之一是是否<path>已经是注册的工作树。
要执行此检查，如果找到匹配项，它会查询find_worktree()并禁止“ add”操作。 然而，为了方便起见，它设置了一个过于宽泛的网络，以允许用户通过速记来识别工作树，以保持最少的输入。 例如，它执行后缀匹配，给定子树“ ”和“ ”，当仅询问“ ”时可以正确选择后者。find_worktree()<path>
find_worktree()
foo/barfoo/bazbaz

" add" 验证知道它正在询问的确切路径，因此这种基于启发式的匹配充其量对于这个用例是有问题的，最坏的情况可能会意外地解释<path>为匹配现有的工作树并错误地将其报告为已经即使没有注册。
（实际上，validate_worktree_add()已经包含一个特殊情况，以避免意外匹配主工作树，正是由于这个问题。）

避免与现有工作树潜在的意外匹配问题，而是利用find_worktree_by_path()which 确定性匹配路径，而不应用由find_worktree().

和：

worktree: 改进find_worktree()文档

^{签字人：Eric Sunshine}

更好地解释它find_worktree()的主要目的是根据用户的输入定位工作树，这可能是识别工作树而不是实际路径的某种速记。

例如，用户可以用来标识工作树的一种速记是通过唯一的路径后缀（即在路径“ foo/bar”和“ foo/baz”处给定工作树，后者可以简单地标识为“ baz”）。
实际启发式find_worktree()的用途来选择worktree可能在将来扩展（例如，有一天它可以允许worktree选择<id>了的.git/worktrees/<id>/管理目录），因此文档不提供如何进行匹配精确的描述，而不是把开放式以允许未来的增强。

虽然它，滴的非NULL的要求提prefix，因为NULL长期以来被允许。

例如，prefix_filename()明确允许NULL自116fb64e43（prefix_filename：支线长度参数，2017年3月20日，Git的v2.13.0-RC0），以及find_worktree()本身因为e4da43b1f0 (prefix_filename：收益新分配的字符串，2017年3月20日，Git的v2.13.0-RC0 ）。

请注意，同一工作树目录只能注册​​一次，但“ git worktree move”允许违反此不变量，这已在 Git 2.28（2020 年第 3 季度）中得到纠正。

见提交810382e，提交d179af6，提交916133e，提交4a3ce47，提交dd9609a，提交1b14d40（2020年6月10日），并提交c9b77f2由（2020年6月8日）埃里克阳光（sunshineco）。
^{（由Junio C gitsterHamano合并-- --在提交 9740ef8 中，2020 年 6 月 22 日）}

在 Git 2.28（2020 年第 3 季度）中，同一工作树目录只能注册​​一次，但“git worktree移动”允许违反此不变量，这已得到纠正。

见提交810382e，提交d179af6，提交916133e，提交4a3ce47，提交dd9609a，提交1b14d40（2020年6月10日），并提交c9b77f2由（2020年6月8日）埃里克阳光（sunshineco）。
^{（由Junio C gitsterHamano合并-- --在提交 9740ef8 中，2020 年 6 月 22 日）}