 Myfro9
|
10f436cfde
|
sync: BOWEI_US 2026-09-02
|
2026-09-02 15:35:47 -05:00 |
|
|
Myfro9andClaude Opus 5
|
e39e852853
|
tools-sync: 增加 ls-remote 同步闸门，并记下 gitea 空 pack 故障的排查法
这次同步事故的教训不是服务器坏了，而是坏了没人知道：pull --rebase 一失败脚本
就退出，push 从没走到，3 个 commit（含整个 bmem skill）在本机躺了 8 天，报告里
却算作"已知故障、待恢复"。而 ls-remote 这 8 天一直是好的。
- sync_repos.ps1 增 Assert-RemoteInSync：push 后（及 -DryRun 时）用 ls-remote 比对
origin/<branch> 的实际 sha，不一致就 FAIL 并报出滞留/落后的 commit 数。
远端分支不存在时单独报错，避免那两个计数被静默地按 HEAD 算出误导性数字。
- SKILL.md 阶段 1 写明闸门是硬性的：服务端故障是原因不是结果，不得报成已同步。
- SKILL.md 新增 bad pack header / early EOF 的排查阶梯（三步各排掉一层），并记下
根因：全局 gitconfig 被注入 [uploadpack] packObjectsHook，把 pack-objects 换成
了空转脚本。附带提醒 HOME 是 /data/gitea/home 而非 /data/git，以及这是一条
完整 RCE 链、要连 hook 与 /tmp 载荷一起清。
- bmem/SKILL.md 的"已知边界"改为已修复，避免继续把普通的没 pull 误判成服务端故障。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015tMFjKGgxdmxJ28dyXdx1u
|
2026-09-02 14:57:50 -05:00 |
|
|
Myfro9
|
2b873a1f4d
|
sync: WIN10-I9-64G 2026-07-20
|
2026-07-20 18:28:34 +08:00 |
|
|
Myfro9
|
c15c5c51e8
|
sync: WIN10-I9-64G 2026-07-20
|
2026-07-20 18:20:36 +08:00 |
|
|
Myfro9
|
96b014edb3
|
sync: WIN10-I9-64G 2026-07-20
|
2026-07-20 18:18:50 +08:00 |
|
|
Myfro9
|
2ef32a9dcc
|
sync: WIN10-I9-64G 2026-07-20
|
2026-07-20 18:14:49 +08:00 |
|