除了“猜测远程分支”之外,正如我在另一个答案中解释的那样,Git 2.18(2018 年第二季度)将提供一个新功能:
“ git worktree add
”学会检查现有分支。
请参阅Thomas Gummerer ( ) 的提交 f60a7b7、提交 6427f87、提交 2c27002、提交 d861d34(2018 年 4 月 24 日)。
帮助者:Eric Sunshine ( )。(由Junio C Hamano 合并 -- --在提交 10174da中,2018 年 5 月 23 日)tgummerer
sunshineco
gitster
工作树:教“ add
”检查现有的分支
当前,“ git worktree add <path>
”默认创建一个以路径的基本名称命名的新分支。
如果已存在具有该名称的分支,则该命令拒绝执行任何操作,除非--force
给出了 ' ' 选项。
但是,我们可以做得比这更好一些,如果没有在其他任何地方签出,请检查分支。
这将帮助只想将现有分支检出到新工作树中的用户,并节省一些击键。
由于当前的行为是简单的 ' die()
' 当具有路径基本名称名称的分支已经存在时,这里不存在向后兼容性问题。
die()
如果分支在另一个工作树中签出,我们仍然会' ',除非--force
标志被传递。
该文档现在指出:
$ git worktree add --track -b <branch> <path> <remote>/<branch>
如果<commit-ish>
省略且既不使用也不-b
使用,则为方便起见,新工作树与以命名的分支(称为 )相关联。-B
--detach
<branch>
$(basename <path>)
- 如果
<branch>
不存在,则会自动创建一个基于 HEAD 的新分支,就像-b <branch>
给定的一样。
- 如果
<branch>
确实存在,它将在新的工作树中检出,如果它没有在其他任何地方检出,否则该命令将拒绝创建工作树(除非--force
使用)。
git worktree add
Git 2.30(2021 年第一季度)修复了在“ ” (man)子命令中带有两个占位符的错误消息的表述。
请参阅Matheus Tavares ( ) 的提交 b86339b(2020 年 11 月 20 日)。(由Junio C Hamano 合并——在提交 f73ee0c中,2020 年 11 月 30 日)matheustavares
gitster
签字人:Matheus Tavares
审核人:Eric Sunshine
git worktree add
( man ) (without --force
) 当给定一个已经注册为工作树的路径并且该路径在磁盘上丢失时会出错。
但是cmd
和path
字符串打开错误消息。
让我们解决这个问题。
这是关于错误消息:
<path> is a missing but locked worktree
use '<cmd> -f -f' to override, or 'unlock' and 'prune' or 'remove' to clear
或者:
<path> is a missing but already registered worktree
use '<cmd> -f' to override, or 'unlock' and 'prune' or 'remove' to clear
从评论:
它不起作用!我尝试git worktree add ../north north
,正如我所说,它给了我一个致命的错误:
'north' is already checked out at 'C:/Source/nis'
该错误消息现在应该更清楚(2022 年第一季度)。
在 Git 2.35(2022 年第一季度)中,“ git worktree add
” (man)向标准输出流显示“正在准备工作树”消息,但是当它失败时,来自die()
标准错误流的消息。
根据程序结束时刷新 stdio 流的顺序,这会导致输出混乱。
它已通过将所有闲聊消息发送到标准错误流来纠正。
请参阅Eric Sunshine ( ) 的提交 b502524和提交 da8fb6b(2021 年 12 月 2 日)。(由Junio C Hamano 合并——在提交 986eb34中,2021 年 12 月 15 日)sunshineco
gitster
报告人:Baruch Burstein
签字人:Eric Sunshine
不保证刷新标准输出和标准错误流的顺序在平台或libc
实现之间是相同的。
如果在错误 (stderr) 输出之后刷新正常 (stdout) 输出,则这种确定性的缺乏可能导致异常和可能令人困惑的输出。
例如,以下输出清楚地表明由于致命错误导致的失败:
% git worktree add ../foo bar
Preparing worktree (checking out 'bar')
fatal: 'bar' is already checked out at '.../wherever'
已报告在 Microsoft Windows 上显示为:
% git worktree add ../foo bar
fatal: 'bar' is already checked out at '.../wherever'
Preparing worktree (checking out 'bar')
这可能会让读者误以为该命令以某种方式恢复并运行完成,尽管出现了错误。
之所以会出现此问题,是因为“闲聊”状态消息“Preparing worktree”被发送到 stdout,而“致命”错误消息被发送到 stderr。
Git 中的一个常见做法是将“闲聊”消息发送到 stderr。
因此,更合适的解决方法是git-worktree
通过将其闲聊消息发送到 stderr 而不是当前情况下的 stdout 来调整以符合该实践。
可能有人担心将消息从 stdout 重定位到 stderr 可能会破坏现有工具,但是,这些消息已经国际化,因此不稳定。
而且,事实上,“Preparing worktree”消息已经成为2c27002中一些重大变化的主题(“ worktree
:在创建新工作树时改进消息”,2018-04-24,Git v2.18.0-rc0 --合并列于第 6 批)。
此外,还有现有的先例,例如68b939b(“ clone
:将诊断消息发送到 stderr”,2013-09-18,Git v1.8.5-rc0 -- merge)同样将“闲聊”消息从 stdout 重新定位到 stderr for git-克隆。