加载失败
Beagle 是一个将源码作为 AST 树而非纯文本来存储的源码管理尝试，讨论围绕这种“把语法结构当作事实真相”的利弊展开。历史上大多数 SCM（如 Git）以文本差异为核心，因格式化或重排引发的合并冲突长期存在；因此有人希望用 AST 消除这些无意义冲突。评论里提到的关联技术包括 tree-sitter（一种增量解析库，用于多语言解析）、semantic merge（基于语义的合并技术）、CRDTs（用于分布式并发编辑的数据结构）、Unison（一个将代码作为内容寻址值存储的编程语言/版本控制系统）、Coccinelle/Spatch（Linux 内核的源代码转换工具）和 Ataraxy-Labs/sem（一个在 Git 中存储 AST 操作的项目）。讨论基于的主要前提是：AST 可降低格式化摩擦并增强工具化，但会带来可读性、diff 审查、解析器维护与采用门槛等实务问题。
支持者认为把源码以AST存储能根治由文本格式化引起的一类无意义合并冲突，从而减少为遵守风格指南而产生的摩擦。评论举例说与确定性格式化工具（如 rustfmt）配合、编辑器在编辑时即刻格式化，可以把样式从协作流程中剥离。此方法还可以促成“file-less”或按函数/操作聚焦的编辑体验，让开发者在逻辑单元上协作而非在文件边界间切换，Unison 被提作更激进但相关的尝试。总体观点是：把语法/语义层作为首要事实真相，能让重构、语义合并等自动化工具更可靠并提升协作流畅度。
反对者认为文本是人类阅读、修改与推理的自然层次，把 AST 当作核心存储会引入额外的转换层（source ↔ AST），增加认知负担并使 diff 不直观。评论指出最终审查、回滚和补丁审阅往往仍然依赖文本差异，因此把 AST 当作“事实真相”会导致不得不为可读的文本差异再构建层。还有人提到用 CRDTs 做存储变换在并发语义上难以推理，而专门的 semantic merge 或把 AST 用作工具层（在每次提交时转换）比把它作为持久化核心更可行。结论倾向于将 AST 驱动的能力作为源代码之上的工具链，而非替代文本的基本事实层。
有人担心要支持所有编程语言并跟随语言演化，解析器维护会是巨量工作且解析器回归可能造成灾难性后果。对此也有回应指出可以把解析工作外包给 tree-sitter（一个由社区维护的增量解析库），借助其已有对多语言语法的支持来降低重复劳动。即便使用 tree-sitter，评论仍提醒存在解析器版本兼容、边缘语法和回归的风险，需要设计回滚与保守策略。换言之，解析依赖能缓解部分实现难度，但并不能完全免除长期维护与兼容性挑战。
评论提到多个现有项目和工具作为参考，表明概念并非完全空想但实践有难点。Ataraxy-Labs/sem 被列为把 AST 操作存入 Git 的实现示例；Linux 社区的 Coccinelle/Spatch 是面向内核的源代码变换工具；大型公司也有内部的 AST 驱动工具链，用于代码重构和审核。另有评论提到 rustfmt 的确定性格式化是解决样式冲突的现实可行方案，而 Unison 被当作更激进的“放弃文本”的范式代表，但其采用遭遇阻力。总体观点是已有可借鉴的实现与工具，但在可用性、兼容性与社区采用上仍需权衡。
AST: 抽象语法树（AST）：将源代码解析为结构化的树状表示，突出语法与结构而非文本字符，便于进行语义级别的变换、重构与分析。
tree-sitter: tree-sitter（一个增量解析库和语法分析器生成器）：为多种编程语言提供高效的增量解析和语法树构建，常被编辑器和语言工具用作解析后端。
CRDTs: CRDTs（Conflict-free Replicated Data Types，无冲突复制数据类型）：一类用于分布式并发编辑的数据结构，强调可合并性和无中央协调，但在表达代码语义冲突时不如专门的语义合并直观。
semantic merge: semantic merge（语义合并）：基于代码语义而非纯文本进行的合并技术，目标是减少因格式或位置变化造成的伪冲突，保留逻辑层面的更改。