介绍
(1) 发表：EMNLP'24
(2) 背景
现有方法通常存在一些缺点，例如只关注变化的行是不够的，或者在变化周围包含不相关的行会带来噪声。如图 1 所示，添加和删除的代码实际上是相同的，只是位置不同，导致代码更改定义不明确。此外，由于缺乏程序依赖关系分析，更改的行和程序的未更改部分之间的关联尚不清楚
(3) 贡献
基于代码属性图（CPG）理论的许多静态分析工具，本文提出了一个上下文感知的 Prompt。同时构建了一个上下文增强的的代码数据集 CODEC 用于提交信息生成
工作
(1) CODEC 数据集
由于现有数据集缺乏对代码更改上下文的监督信号，因此我们为本文所研究的任务构建了自己的数据集
-
收集：使用 PyDriller 在 Github 上手机至少 1000 Star 的 Java 存储库，除了源代码更改外，还记录了更改部分的上下文
-
过滤：使用了四种过滤规则
① 当更改的行数较多时，大多数自动生成的注释都是不可靠的，因此超过 20 行的更改将被忽略
② 提交信息应有长度限制，少于 5 个单词的消息没有信息，而大于 150 个单词的消息可能会令人困惑
③ 仅更改 Java 文件
④ 删除不相关的信息，例如 issueID、commitID 和 URL -
优化：根据之前的研究，仅考虑提交信息的第一句话。本文还给构建了一个 Bi-LSTM 模型以进保留 Why/What 的信息
(2) COMMIT 模型
-
构建 Added-Deleted Context Graph：使用静态代码分析工具 Joern3 为更改前后的代码构建两个 CPG，分别用于删除的行和添加的行，保留删除或添加部分的依赖节点。通过组合两个 CPG 得到 ADCG，然后可以通过程序切片从 Diffs 中提取 ADCG 节点指示的有用上下文语句
-
依赖提取算法：考虑到过度平滑和平衡模型复杂性和效率之间的负面影响，我们将依赖关系的范围限制在一定深度。构建的算法可以在特定深度内从 ADCG 访问更改的语句
ADCG 中每个节点对应一条语句（或行），边表示语句之间的数据依赖或控制依赖。算法首先将变化的代码行作为初始节点集合，并基于它们构建初始的切片，然后以代码切片为工作队列，迭代地取出依赖关系：如果某个依赖片段的深度未超过预设的依赖深度，就检查其源节点或目标节点；一旦发现新的相关节点（即在依赖映射中能连接到尚未加入的节点），就将其加入依赖节点集合，并把新的依赖边加入切片中，等待后续处理。这样，依赖图会像“向外扩散”一样逐步更新。最后，算法收集所有相关节点的代码行作为结果，并将最初的变化行去除，只保留通过依赖传播得到的受影响行
(3) Prompt 设计
将每个提示扩展成四个特定的模版，每个模板都由任务提示、代码差异和基本事实提交消息组成，在实验阶段分别对 T1~T4 进行实验来验证对于提示变化方面的鲁棒性
最终的优化函数如下：
实验
总而言之就是取得了 SOTA，然后验证了 Context-Rich 信息的正面提升
总结
解决了现有提交信息生成未考虑上下文依赖关系变化的问题，并且基于此提出了一个方法和数据集