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

cityzz 发表于 Dev

Cityzz

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

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

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

冯

git worktree-细节提到：

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

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

Git 2.20（Q4 2018）修复了一个错误：如果缺少路径（例如，手动删除），则可以在多个工作树条目下注册相同的路径。
另外，为方便起见，请扩展--force适用的案例数。

参见Jeff King（）提交684e742（2018年8月30日）。请参见Eric Sunshine（）的提交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日）阮泰玉维战（pclouds）。
参见Elijah Newren（）提交的commit a8c754d（2018年10月21日）。^{（通过合并}^{JUNIOÇ滨野-}^-^在^{提交e146cc9}^{11月13日2018）}newren
^gitster

特别是（commit 3a3b9d8）：

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

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

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

无需输入单独的引用空间，而是使当前引用空间中其他工作树的引用可用。
因此，“ HEAD”始终是当前工作树的HEAD，但是我们可以使用“ worktrees/blah/HEAD”来表示名为“ blah”的工作树中的HEAD 。
该语法恰好匹配基础目录结构，这使得实现起来更加容易。

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

此补丁程序还可以从另一个工作树中的一个工作树中指定引用，例如
git log worktrees/foo/HEAD

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

见提交1de16ae通过（2019年3月8日）阮泰玉维战（pclouds）。
帮助：Jeff King（peff）。
^{（通过合并JUNIOÇ滨野- gitster-在提交0d107b1，2019年6月13日）}

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”，当连接到同一存储库的另一个工作树损坏时，它会失败，该错误已得到纠正。

见提交105df73（2019 5月13日），由阮泰玉维战（pclouds）。
^{（通过合并JUNIOÇ滨野- gitster-在提交933f294，2019年7月25日）}

worktree add：容忍损坏的工作树

find_worktree()可能会意外地死出（），因为它使用real_path()的是旧版本。

当它在“混帐worktree添加”'S使用的（在加入cb56f55（worktree：不允许添加相同的路径多次，2018年8月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^合并^--^在^{commit 49e5043中}^{，2020年3月5日）}sunshineco
^gitster

worktree：不允许add后缀匹配欺骗验证

^{报道人：卡梅隆·冈宁}
^{签名人：埃里克·阳光}

在核准为新工作树的有效位置之前，“ ”会进行各种检查。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()确定性的匹配路径来避免与现有工作树发生潜在意外匹配的问题，而无需应用进行的任何魔术速记匹配find_worktree()。

和：

worktree：改进find_worktree()文档

^{签字人：埃里克·阳光}

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

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

在此期间，很久prefix以来NULL就一直允许提及非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（Q3 2020）进行了更正。

请参阅Eric Sunshine（）的提交810382e，提交d179af6，提交916133e，提交4a3ce47，提交dd9609a，提交1b14d40（2020年6月10日）和提交c9b77f2（2020年6月8日）。^{（通过合并}^{JUNIOÇ滨野-}^-^在^{提交9740ef8}^{6月22日2020）}sunshineco
^gitster

在Git 2.28（2020年第3季度）中，同一工作树目录仅必须注册一次，但是“git worktree移动”允许违反此不变式，已更正。

worktree：修剪重复的条目引用相同的工作树路径

^{签字人：埃里克·阳光}

链接的工作树的基本限制是，只有一个工作树与特定路径相关联，因此“ git worktree add”明确禁止在与现有注册工作树相同的位置创建新工作树。

尽管如此，用户仍然可以通过将中的管理文件混为一谈来“自拔” .git/worktree/<id>/。

更糟糕的是，“ git worktree move”很粗心，并且允许将工作树移动到已注册但丢失的工作树上（例如，如果工作树在可移动媒体上，则会发生这种情况）。

例如：
$ git clone foo.git
$ cd foo
$ git worktree add ../bar
$ git worktree add ../baz
$ rm -rf ../bar
$ git worktree move ../baz ../bar
$ git worktree list
.../foo beefd00f [master]
.../bar beefd00f [bar]
.../bar beefd00f [baz]
通过教导“ git worktree prune”来检测何时多个工作树与同一路径相关联，从而帮助用户从这种损坏中恢复。

和：

worktree：修剪链接的工作树引用主工作树路径

^{报道人：乔纳森·穆勒}
^{签名人：埃里克·阳光}

“ git worktree prune”会检测何时多个条目与同一路径相关联，并修剪重复项。

但是，它不会检测链接的工作树何时指向主工作树的路径。
尽管“ git worktree add”不允许使用与主工作树相同的路径来创建新的工作树，但是即使用户不使用.git/worktree/<id>/管理文件，也可能在Git的控制范围之外出现这种情况。

例如：
$ git clone foo.git
$ git -C foo worktree add ../bar
$ rm -rf bar
$ mv foo bar
$ git -C bar worktree list
.../bar deadfeeb [master]
.../bar deadfeeb [bar]
扩展“ git worktree prune”以检测链接的工作树何时与主工作树的路径相关联，从而帮助用户从此类损坏中恢复过来。

请注意，Git 2.30确实列出了锁定的工作树：

参见commit c57b336：

工作树：教list注释已锁定的工作树

“ git worktree list”显示了到工作树的绝对路径，已检出的提交以及分支的名称。立即锁定哪个工作树（如果有）不是很明显。

“ git worktree remove”拒绝删除带有错误消息的锁定的工作树。如果“ git worktree list”告诉哪个工作树被锁定在其输出中，则用户甚至不会尝试删除这样的工作树，或者会意识到“ git worktree remove -f -f <path>”是必需的。

教“ git worktree list”将“ locked”附加到其输出。
命令的输出如下所示：
$ git worktree list
/path/to/main             abc123 [master]
/path/to/worktree         456def (detached HEAD)
/path/to/locked-worktree  123abc (detached HEAD) locked