Gas Town 如何用 gt polecat gc 和 gt polecat stale 识别并清理陈旧 polecat 与其分支【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown在 Gas Town 中polecat 每接一次任务就会用带时间戳的独立分支和 git worktree 来隔离工作。会话崩溃、陈旧 polecat 被修复、合并完成之后这些 sandbox 和分支不会自动消失长期运行下来polecat/*分支会不断堆积。这条路径解决的就是这个具体任务先用gt polecat stale rig找出哪些 polecat 已经是陈旧状态用--cleanup预览并销毁它们再用gt polecat gc rig清扫剩余的孤儿分支和时间戳分支。前提是你已经装好gt并至少在一个 rig下文示例用文档中的 rig 名greenplace请替换成你自己的 rig 名里跑过 polecat。这两条命令的分工见 docs/CLEANUP.md 的清理分层gt polecat gc属于 L2「Git artifacts」层只动分支gt polecat stale --cleanup走的是 nuke 路径L3「Agents/sessions」层会连同 session、worktree、分支和 agent bead 一起清掉。先判断什么样的 polecat 会被判为 stalegt polecat stale的判定条件见命令帮助与 internal/cmd/polecat.go 中polecatStaleCmd的定义没有活跃的 tmux 会话落后 main 超过阈值提交数默认 20或者没有 agent bead没有可能丢失的未提交工作。三个条件同时满足才算 stale。也就是说带着未提交改动的 polecat 不会被这条路径销毁——这一点与 Witness 自动巡检的行为一致自动路径遇到有未提交工作的 sandbox 时不直接 nuke而是升级escalate由人来决定见 docs/design/polecat-lifecycle-patrol.md 的「The Orphaned Sandbox」一节。第一步识别陈旧 polecatgt polecat stale greenplace把greenplace换成你的 rig 名。命令开头会打印Detecting stale polecats in rig (threshold: 20 commits behind main)...随后逐个列出候选 polecat 的状态最后以汇总行收尾Summary: N stale, M active文档示例中的N、M是运行时的实际数字不是固定值。两个常用变体gt polecat stale greenplace --threshold 50把「落后多少提交算陈旧」的阈值从默认的 20 调成 50适合 main 推进很快、默认阈值容易误报的场景gt polecat stale greenplace --json输出机器可读的 JSON方便脚本消费。如果汇总行显示 0 stale说明当前没有需要清理的陈旧 polecat分支侧仍可以单独跑 gc见第四步。第二步预览清理范围--cleanup是破坏性操作对每个 stale polecat 执行 nuke杀掉可能残留的 session、删除 worktree、删除分支、关闭 agent bead。先用 dry-run 确认范围gt polecat stale greenplace --cleanup --dry-run输出形如Would clean up N stale polecat(s):后面列出会被清理的 polecat 名单实际不删除任何东西。核对名单里没有出现你还想保留的 sandbox 后再执行真正的清理。需要知道的一点stale --cleanup与gt polecat nuke共用同一条清理路径源码中该路径被标注为两者共同的 canonical cleanup path删除 worktree 时对 stale polecat 绕过 nuke 的额外安全检查。之所以安全是因为进入这个路径的前提是第一步的 stale 判定——活跃会话和有未提交工作的 polecat 已经被排除。清理完成后还会自动触发一次孤儿进程清理这部分在 docs/CLEANUP.md 的 InternalAutomatic / Side-Effect表格中记录。第三步执行清理并验证gt polecat stale greenplace --cleanup存在 stale polecat 时输出依次为Cleaning up N stale polecat(s)...完成后打印Nuked N stale polecat(s).。验证方式就是原路重跑检测gt polecat stale greenplace汇总行应为Summary: 0 stale, M active。若某个 polecat 仍然被报为 stale 且清理没生效不要盲目再跑--cleanup先对单个 polecat 跑恢复检查gt polecat check-recovery greenplace/Toast该命令基于cleanup_status、active_mr和 merge queue 状态给出三种判定之一SAFE_TO_NUKE清理状态为 clean、active_mr 已终结、工作已提交合并队列、NEEDS_MQ_SUBMITgit 干净但工作从未进入合并队列、NEEDS_RECOVERY需要恢复。文档明确建议 Witness 把后两种情况升级到 Mayor 处理手动操作时同样应停止自动清理、人工确认。第四步用 gt polecat gc 清扫剩余分支即使 sandbox 已经清掉git 仓库里可能还留着两类分支已不存在的 polecat 留下的分支孤儿分支以及同一 polecat 的历史时间戳分支只应保留当前那一个。这正是gt polecat gc的职责。先预览不删任何东西gt polecat gc greenplace --dry-run输出会逐条区分Would delete: branch将删除与Keep (in use): branch当前 polecat 在用保留最后给出Would delete N branch(es), keep M。确认预览结果只包含polecat/*下确实陈旧的分支后正式执行gt polecat gc greenplace结果两种No stale branches to clean up.已经干净或Deleted N stale branch(es).。再跑一次--dry-run看到Would delete 0 branch(es)即完成验证。可选清理已完全合并的分支如果你的目标还包括删除已经合进 main 的 polecat 分支gc 不处理这类分支它只动孤儿分支和历史时间戳分支用另一条命令gt polecat prune greenplace --dry-rungt polecat prune rig只做安全删除等价于git branch -d只删完全合并的分支同样支持--dry-run预览加--remote时一并清理 origin 上已合并的 polecat 远端分支。它与 gc 是并列的两条分支清理路径按需要选用。限制与边界检测基于 tmux 会话活性并保护暂停状态paused states的 polecat见 docs/design/polecat-lifecycle-patrol.md 的实现状态表正在跑活或处于受保护状态的 polecat 不在清理范围内。阈值 20 是默认值而非硬编码上限--threshold调大可以减少「刚接活但还没跟上 main」的误报调小则更激进。Witness 巡检本身也会持续调用同一套 stale 检测逻辑DetectStalePolecats()手动命令的意义在于让你自己核对名单、控制节奏而不是替代巡检。--cleanup与 gc 的删除都是不可逆的分支删掉后未推送的内容无法找回。所以本文顺序固定为先stale检测、再 dry-run 预览、最后才真正删除。相关文档docs/CLEANUP.md全部清理命令目录与 L0–L5 分层含gt polecat nuke、gt polecat check-recoverydocs/concepts/polecat-lifecycle.mdidentity / sandbox / session 三层模型理解「哪些东西会被删、哪些会保留」的依据docs/design/polecat-lifecycle-patrol.mdWitness 巡检、stale/zombie 检测的实现与边缘情况【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Gas Town 如何用 gt polecat gc 和 gt polecat stale 识别并清理陈旧 polecat 与其分支？
Gas Town 如何用 gt polecat gc 和 gt polecat stale 识别并清理陈旧 polecat 与其分支【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown在 Gas Town 中polecat 每接一次任务就会用带时间戳的独立分支和 git worktree 来隔离工作。会话崩溃、陈旧 polecat 被修复、合并完成之后这些 sandbox 和分支不会自动消失长期运行下来polecat/*分支会不断堆积。这条路径解决的就是这个具体任务先用gt polecat stale rig找出哪些 polecat 已经是陈旧状态用--cleanup预览并销毁它们再用gt polecat gc rig清扫剩余的孤儿分支和时间戳分支。前提是你已经装好gt并至少在一个 rig下文示例用文档中的 rig 名greenplace请替换成你自己的 rig 名里跑过 polecat。这两条命令的分工见 docs/CLEANUP.md 的清理分层gt polecat gc属于 L2「Git artifacts」层只动分支gt polecat stale --cleanup走的是 nuke 路径L3「Agents/sessions」层会连同 session、worktree、分支和 agent bead 一起清掉。先判断什么样的 polecat 会被判为 stalegt polecat stale的判定条件见命令帮助与 internal/cmd/polecat.go 中polecatStaleCmd的定义没有活跃的 tmux 会话落后 main 超过阈值提交数默认 20或者没有 agent bead没有可能丢失的未提交工作。三个条件同时满足才算 stale。也就是说带着未提交改动的 polecat 不会被这条路径销毁——这一点与 Witness 自动巡检的行为一致自动路径遇到有未提交工作的 sandbox 时不直接 nuke而是升级escalate由人来决定见 docs/design/polecat-lifecycle-patrol.md 的「The Orphaned Sandbox」一节。第一步识别陈旧 polecatgt polecat stale greenplace把greenplace换成你的 rig 名。命令开头会打印Detecting stale polecats in rig (threshold: 20 commits behind main)...随后逐个列出候选 polecat 的状态最后以汇总行收尾Summary: N stale, M active文档示例中的N、M是运行时的实际数字不是固定值。两个常用变体gt polecat stale greenplace --threshold 50把「落后多少提交算陈旧」的阈值从默认的 20 调成 50适合 main 推进很快、默认阈值容易误报的场景gt polecat stale greenplace --json输出机器可读的 JSON方便脚本消费。如果汇总行显示 0 stale说明当前没有需要清理的陈旧 polecat分支侧仍可以单独跑 gc见第四步。第二步预览清理范围--cleanup是破坏性操作对每个 stale polecat 执行 nuke杀掉可能残留的 session、删除 worktree、删除分支、关闭 agent bead。先用 dry-run 确认范围gt polecat stale greenplace --cleanup --dry-run输出形如Would clean up N stale polecat(s):后面列出会被清理的 polecat 名单实际不删除任何东西。核对名单里没有出现你还想保留的 sandbox 后再执行真正的清理。需要知道的一点stale --cleanup与gt polecat nuke共用同一条清理路径源码中该路径被标注为两者共同的 canonical cleanup path删除 worktree 时对 stale polecat 绕过 nuke 的额外安全检查。之所以安全是因为进入这个路径的前提是第一步的 stale 判定——活跃会话和有未提交工作的 polecat 已经被排除。清理完成后还会自动触发一次孤儿进程清理这部分在 docs/CLEANUP.md 的 InternalAutomatic / Side-Effect表格中记录。第三步执行清理并验证gt polecat stale greenplace --cleanup存在 stale polecat 时输出依次为Cleaning up N stale polecat(s)...完成后打印Nuked N stale polecat(s).。验证方式就是原路重跑检测gt polecat stale greenplace汇总行应为Summary: 0 stale, M active。若某个 polecat 仍然被报为 stale 且清理没生效不要盲目再跑--cleanup先对单个 polecat 跑恢复检查gt polecat check-recovery greenplace/Toast该命令基于cleanup_status、active_mr和 merge queue 状态给出三种判定之一SAFE_TO_NUKE清理状态为 clean、active_mr 已终结、工作已提交合并队列、NEEDS_MQ_SUBMITgit 干净但工作从未进入合并队列、NEEDS_RECOVERY需要恢复。文档明确建议 Witness 把后两种情况升级到 Mayor 处理手动操作时同样应停止自动清理、人工确认。第四步用 gt polecat gc 清扫剩余分支即使 sandbox 已经清掉git 仓库里可能还留着两类分支已不存在的 polecat 留下的分支孤儿分支以及同一 polecat 的历史时间戳分支只应保留当前那一个。这正是gt polecat gc的职责。先预览不删任何东西gt polecat gc greenplace --dry-run输出会逐条区分Would delete: branch将删除与Keep (in use): branch当前 polecat 在用保留最后给出Would delete N branch(es), keep M。确认预览结果只包含polecat/*下确实陈旧的分支后正式执行gt polecat gc greenplace结果两种No stale branches to clean up.已经干净或Deleted N stale branch(es).。再跑一次--dry-run看到Would delete 0 branch(es)即完成验证。可选清理已完全合并的分支如果你的目标还包括删除已经合进 main 的 polecat 分支gc 不处理这类分支它只动孤儿分支和历史时间戳分支用另一条命令gt polecat prune greenplace --dry-rungt polecat prune rig只做安全删除等价于git branch -d只删完全合并的分支同样支持--dry-run预览加--remote时一并清理 origin 上已合并的 polecat 远端分支。它与 gc 是并列的两条分支清理路径按需要选用。限制与边界检测基于 tmux 会话活性并保护暂停状态paused states的 polecat见 docs/design/polecat-lifecycle-patrol.md 的实现状态表正在跑活或处于受保护状态的 polecat 不在清理范围内。阈值 20 是默认值而非硬编码上限--threshold调大可以减少「刚接活但还没跟上 main」的误报调小则更激进。Witness 巡检本身也会持续调用同一套 stale 检测逻辑DetectStalePolecats()手动命令的意义在于让你自己核对名单、控制节奏而不是替代巡检。--cleanup与 gc 的删除都是不可逆的分支删掉后未推送的内容无法找回。所以本文顺序固定为先stale检测、再 dry-run 预览、最后才真正删除。相关文档docs/CLEANUP.md全部清理命令目录与 L0–L5 分层含gt polecat nuke、gt polecat check-recoverydocs/concepts/polecat-lifecycle.mdidentity / sandbox / session 三层模型理解「哪些东西会被删、哪些会保留」的依据docs/design/polecat-lifecycle-patrol.mdWitness 巡检、stale/zombie 检测的实现与边缘情况【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
![[单片机][KEIL5] 参数的意义和使用 L #L @L K #K $, #, %, @, ~, ^](http://pic.xiahunao.cn/yaotu/[单片机][KEIL5] 参数的意义和使用 L #L @L K #K $, #, %, @, ~, ^)
