megatron-commit-tracker

Megatron 提交跟踪器

从官方 Megatron-LM 仓库收集最小且正确的上游变更集，并将规范化产物交给下游技能。所有模式都将 branch 视为一等输入。

核心规则

• 以官方上游仓库作为事实来源：https://github.com/NVIDIA/Megatron-LM。
• 除非用户提供了可明确解析的 PR 或提交，否则必须指定目标 branch。
• 在进行任何语义分析之前，将每个请求规范化为一个 change-set 对象。
• 保持此技能的机械性。不要在此处总结功能演进。
• 跟踪功能时，优先使用 PR 和范围／时间窗口模式，而非单提交模式。
• 将 megatron main 视为有效的探索选项，但不要暗示它与 MindSpeed 有严格映射关系。

支持的请求模式

将用户请求解析为以下模式之一，且仅限一种：

1. pr 用户指定 PR 编号或合并请求 URL 时使用。
2. commit 用户指定一个提交 SHA，并希望在分支上下文中检查该变更时使用。
3. range 用户指定 base_sha..head_sha 时使用。
4. time_window 用户指定分支和一段时间（例如 last 7 days）时使用。
5. scheduled 自动化任务增量检查分支时使用。

必需输出

以 JSON 或 Markdown 代码块的形式生成规范化的 change-set 产物，并在可用时包含以下字段：

{
  "repo": "NVIDIA/Megatron-LM",
  "branch": "core_v0.12.1",
  "source_type": "pr",
  "selector": {
    "pr": 1234,
    "commit": null,
    "base_sha": null,
    "head_sha": null,
    "since": null,
    "until": null
  },
  "resolved": {
    "commits": ["sha1", "sha2"],
    "head_sha": "sha2",
    "base_sha": "sha0"
  },
  "analysis_mode": "summary"
}

另外，还要附上以下信息的简明表格：

• 提交 SHA
• 作者
• 创作日期
• 标题
• 变更文件数

工作流程

1. 将用户请求解析为一种受支持的模式。
2. 根据指定的 Megatron 分支解析请求。
3. 确认输出中明确说明了分支上下文。
4. 仅收集下游所需的原始产物： 提交列表、合并元数据、变更文件、base/head SHA，以及任何关联的 PR 元数据。
5. 除非用户明确要求进行深入分析，否则规范化后即停止。

分支处理

• 绝不默默用 main 替代其他分支。
• 如果请求的名称来自本地约定或发布说明，在执行大量获取操作之前，先对照官方远程仓库验证准确的分支字符串。
• 如果用户提供了提交但未指定分支上下文，仅在分支可明确推断时尝试推断。否则说明需要确认分支。
• 对于定期跟踪，按 repo + branch 保存状态，绝不能仅按仓库保存。
• 对于 main，应将结果描述为探索性上游跟踪，而非可严格用于迁移的对齐结果。

交接

将规范化的 change-set 交给：

• $megatron-change-analyzer，用于功能演进和变更分类
• $megatron-impact-mapper，仅在变更分析确定了相关事件后使用

参考资料

• 阅读 branch-tracking.md，了解分支感知的请求规范化和调度指导。
• 需要确定性的 change-set 结构时，运行 normalize_change_request.py。
• 在假定某个分支别名可获取之前，运行 list_remote_branches.py，验证官方上游远程仓库公开的确切分支名称。
• 运行 fetch_upstream_changes.py，从官方上游仓库收集提交元数据，无需每次手动重建 Git 查询。