1. The proposed approach (Section 4) also looks very straightforward, the claimed 3 novelties are not well reflected in the methodology. I would suggest the authors to consider in-depth what are the key challenges of CMG, and how your approach addressed these challenges with the unique designs.

2. While HisRag aims to retrieve “less,” the paper does not address the computational cost of generating and storing embeddings, maintaining per-user indices, or runtime retrieval in large teams or CI/CD workflows.

3. Injecting similar commit messages from the past could lead to reduced lexical or structural diversity. There is no analysis of whether HisRag causes overfitting to personal style or introduces repetition in generated messages.

4. It’s unclear whether baseline models were re-tuned or re-evaluated under the same training and testing settings as the HisRag-enhanced models, raising concerns about evaluation fairness.
5. The paper does not report the distribution of history lengths across developers and repositories. Given that the approach depends on historical context, it would be valuable to know how history size impacts performance.
6. Beyond narrowing the retrieval scope, could you elaborate on what differentiates HisRag from prior CMG frameworks like REACT? Also, how generalizable is your approach to non-Java languages or less active repositories where historical context may be sparse?
7. Could you justify the sample size used in the human evaluation in terms of statistical significance? Also, were annotators given explicit guidelines? Was inter-annotator agreement measured?

8. In RQ3, what exactly is removed or changed in the “HisRag_COME without modification embedding” variant? Could you clarify what insights this ablation is meant to isolate?

9. Baselines:

The authors’ experimental comparisons are incomplete. Although HisRag is positioned as a RAG-based approach, the paper does not include direct comparisons with widely used RAG methods based on BM25 [51], which are commonly adopted for LLMs in commit message generation tasks. Furthermore, the authors do not compare HisRag with more recent large language model-based approaches, such as the ERICOMMITTER method [68]. ERICOMMITTER is particularly relevant because it also evaluates both lexical-based retrieval (BM25) and semantic-based retrieval (pre-trained code models), offering a broader and stronger benchmark. The omission of these important baselines significantly limits the fairness and completeness of the evaluation and makes it difficult to accurately assess the true advantages of the proposed approach.

• Human Evaluation:

Although a human study is included, the evaluation criteria—Informativeness, Conciseness, and Expressiveness—are not clearly defined. The scoring system ranges from 0 to 4, but the meaning and anchors for each score are not explained, leaving it unclear how these scores relate to actual usefulness or human judgment. This lack of clarity could also be the reason for the large standard deviation observed in the results. Furthermore, the evaluation does not include recent strong models such as DeepSeek, which may achieve the best performance, making the assessment less comprehensive and less informative for practitioners.

Wang, Guoqing, et al. "Is It Hard to Generate Holistic Commit Message?." ACM Transactions on Software Engineering and Methodology 34.2 (2025): 1-28.

1. Can the authors clarify what is fundamentally novel in HisRag compared to existing RAG-based methods like [55], [70], and [68] and standard RAG (based on BM25) or concatenation approaches?
2. Can the authors provide direct comparisons with widely used RAG baselines such as BM25-based RAG [51] and recent methods like ERICOMMITTER [68]?
3. Do the authors have evidence that improvements in B-NORM and BLEU correspond to real quality gains, given the known unreliability of these metrics for LLM-based CMG?
4. Can the authors clearly define the human evaluation criteria, explain the 0–4 scoring system, and consider including recent models like DeepSeek in the human study?
5. Can the authors evaluate HisRag on additional standard datasets such as MCMD to improve comparability and generalizability?

1： 缺点：

评估和比较的范围有限 研究设计和方法有缺陷 表述问题

复现：未提供artifact，没有解释

论文的方法设计需要优化，RQ1和RQ2的区别需要讲明白，它们看起来很像。此外，RQ3需要形成一个研究问题，不然很难理解它们的目的和内容。 就RQ3中的开发者参与，不清楚为什么参与者需要比较生成的message和GT。这个任务可以自动化，要求人类评估的原因要解释清楚。此外，评估commit message的质量没有抓住一些重要的方面，例如可读性（readability）、信息价值（informational value），以及提交代码的相关性。纳入这些定性指标可以提供更全面的评估。两个受试者没有参与的原因也需要解释，为了保证研究的透明性和完整性需要提供相应的理由。

RQ3的设计，缺乏有效定性指标，仅靠定量指标如BLEU来评估性能，难以得出可靠结论。展示的结果没有充分支持作者的论述，需要定性和定量评估来强化研究发现。

prompt的选择原因需要阐述清楚，有一个prompt在图里面展示了，但是文字上又没有解释。对prompt的设计意图以及预期效果的解释能够帮助读者更容易理解。此外，LLMs生成错误的分析也能够帮助理解它们的局限性和需要提升的地方。

需要解决LLMs的上下文限制问题。例如，讨论512个token的输入以及15个token的输出是否足够非常重要。需要解释背后的原因。

GPT3.5和llama 2 7B的比较有问题，使用同一个系列的不同大小的模型能够帮助作者说明不同模型大小和生成消息质量的trade-offs。论文表明不同架构的LLMs存在显著的性能差异，但是需要更多的证据，因为仅比较了两个系列的模型。

需要说清楚确定超参数（温度）的过程。作者应该解释是如何选择这些值的。

2：

缺点：

RQ1中的结果没有差异统计检验，因此不能得出P3和其它Promt不同的原因。

RQ2没有统计检验，新方法是否和SOTA有显著差异

参与调查问卷的人可能有不同的经历，应该进行分组，并说明他们的资历。使用的数据是开源的，因此需要说明有多少开源开发者或者闭源开发者参与。

ChatGPT可能存在数据泄露。

要和一篇文献进行比较：A large-scale empirical study of commit message generation: models, datasets and evaluation。结果和它们相比如何，需要对方法做出哪些调整？

需要统计检验来说明差异性。

作者需要加入以下必要信息：参与者有多少有开源贡献检验？就年限而言他们有什么不同？每个参与者是否都标记了100个commits？有多少被排除在外？有没有根本没标记的评论？参与者的结果是否彼此有显著差异？也许你的方法中闭源开发人员的结果比开源开发人员表现得更好？

3.

缺点：

表述问题

研究问题必须更好地表述和论证

评估问题

缺少重要信息

RQ1和RQ2太像了，需要区分开。我的理解是RQ1的方法利用了LLMtest作为test，而RQ2是基于整个CommitChronicle数据集。然而，这只是我的假设，基于两个RQs中方法的结果是不一样的。然而，论文里没有表述清楚。此外，如果作者在两个RQs里用的是同一个测试集，需要验证表4和表5的结果为什么不一样。

RQ3 人类评估不是一个合适的研究问题。强烈建议改写为一个研究问题，来表述作者想要研究的内容。文中通过让参与者从0-5评估语义相似度是不合理的，这可以用自动化指标计算。人类评估者的作用必须更好地说明。另一个问题是，人类评估者被要求将提交消息与真实提交消息进行比较来评估它们生成的提交消息的感知质量，这由于诱导的偏见而引入了强烈的混淆，从而使估值的结果不可靠。为什么不要求开发人员在实践中采用这个工具，例如在对照实验中呢？

实验设置：作者使用tf-idf来选择最相关的message作为上下文，没有解释为什么使用该方法。

RQ2中作者说搜索最优的温度设置，搜索的结果是什么？请报告调查结果

为什么在RQ3中，作者排除了P2和P4？需要说明原因。

启示：ChatGPT和LLama2的比较是不公平的，因为它们不属于同一个模型系列，也不是同一个量级。公平的比较应该是：ChatGPT对应Claude，或者Llama2的70B。代码大模型也可以用来作比较，因为它们是在code，nl，code comments训练得来的，它们应该能够表现得很好。

同一个模型系列的不同大小可以更清楚地表明模型大小和性能的关系。不同架构的LLMs存在性能差异，这一结果没有充分的证据来证明。

提示应该可读性强

审稿人 1： 1. RQ1和RQ2区别需要区分，看起来很相似 2. RQ3人类评估没有充分说明让人类参加评估的原因，评估指标还应该有：可读性、信息价值以及相关性等。 3. prompt的设计以及预期效果没有详细的解释 4. LLMs的生成的不足的地方需要进行分析，以了解方法的局限性和需要改进的地方 5. 512个token和15个token的选择，不应该做这个限制，或者需要添加说明的理由 6. 使用同一个系列的大模型更具有说服力 7. 超参数的确定的过程需要详细描述，应该解释是如何确定的

审稿人 2： 1. RQ1 中缺少差异的统计检验，因此，不能说提示 3 是否实际上与其他提示类型不同。 2. RQ2 中缺少统计测试。新方法与 SOA 有显着不同吗？ 3. The participants may have varying experience, IMHO they should be grouped and the gains/performance should be reported within the groups of experience. The projects being used in this study are open-source also. Therefore, a clear distinction is needed on how many open .vs. non-open source developers were involved. 4. 表6的标题没有 5. GPT3.5不应该称为ChatGPT 6. 需要有统计测试来检查显着差异和效应大小。 7. 问卷调查也需要材料，有多少参与者有开源贡献经验？他们的经历在没有方面有多少不同。年？ 7 位参与者中的每个参与者是否都标记了所有 100 个提交？ 有多少人被排除在外？是否有任何评论根本没有被标记？参与者的结果是否有显着差异？也许您的方法对于闭源体验组来说比开源开发人员组表现得更好？

审稿人 3： 1. 研究问题结构不佳：RQ1 和 RQ2 过于相似，应合并为一个研究问题，因为尚不清楚它们旨在研究的不同方面是什么。我的理解是，回答 RQ1 的方法利用 LLMtest 作为测试集，而回答 RQ2 的方法基于整个 CommitChronicle 数据集。 然而，这只是我的假设，基于他们的方法在两个 RQ 中的结果不同的事实。不幸的是，论文中没有明确说明这一点。相反，如果作者在两个实验设置中使用相同的测试集，他们应该证明为什么他们的方法的结果不同（如表 IV 和表 V 所示）。 2. RQ3是“人类评估”，这不是一个适当的研究问题。我强烈建议将其重新表述为一个问题，以明确作者打算研究的内容。为了实现这一目标，作者设计并实施了一项用户研究，要求参与者以 0 到 5 的等级评估生成的提交消息和事实真相之间的语义相似性。 我不清楚为什么必须这样做作为用户研究来完成，因为这是一项可以通过计算文本相似性指数自动执行的任务。因此，使用人类评估员必须有更好的理由。 用户研究的另一个问题是，人类被要求通过将 LLMs 生成的提交消息与真实提交消息进行比较来评估它们的感知质量，这会由于诱发偏差而引入强烈的混杂性，从而导致估值结果不可靠。为什么不要求开发人员在实践中采用这个工具，例如在对照实验中？ 3. 作者使用 Tf-Idf 选择最相关的先前提交消息，用作基于 LLM 的提交消息生成的上下文。论文中没有解释为什么使用这种方法，必须证明其合理性。 4. 在 RQ2 中，作者表示他们正在寻找最佳温度设置。此搜索的结果是什么？请报告本次调查的结果。 5. 作者指出，在提交消息生成方面，ChatGPT 应优先于 LLama-2。然而，这两个模型之间的比较本质上是不公平的，因为 ChatGPT 是一个比实验中使用的 LLama-2 模型（Llama-2-7b-chat，最小的 LLama-2 变体）大得多的模型。 两个模型之间的性能差异可能是由于模型的大小而不是模型系列造成的。公平的比较是使用 ChatGPT 的直接竞争对手，例如 Claude、更大版本的 LLama-2（例如 13b、70b）或其他开源模型。 本研究可以探索特别适合编码任务的模型，因为作者构建的提示包含代码更改。由于这些模型是根据代码进行训练的，并通过代码、自然语言或代码注释进行提示，因此它们可以在此类任务中表现良好。 6. 同一模型系列具有不同的大小将允许作者提供关于模型大小和生成的提交消息的质量之间的权衡的指南。 7. 最后，论文指出，他们的方法有可能帮助开发人员自动生成提交消息。不幸的是，根据本文提供的经验证据，尚不清楚如何支持这一主张。特别是，就用户研究而言，必须进行不同的设计才能调查这方面，正如我之前的评论中所讨论的。 8. 演示质量：总体而言，我发现这篇论文的许多部分难以阅读和理解，也是由于缺乏重要信息。在第五节中，作者将第一个提示（P1）称为“最简单的提示”。 提示应以更正式、更全面的方式呈现，以确保可复制性和可验证性。提示仅如图3所示，不便于阅读。我建议作者更好地在文本中描述提示，并以更易读的格式提供它，因为提示是LLMs研究的重要组成部分。 9. 表IV描述为“()内的内容表明改进......”，但该表括号内没有任何内容。

A

缺点：

l RQ1的结果和分析不明确

l 动机和创新性不明确

l 表述错误

历史提交消息之前被提出来了，检索增强方法也在多种软工任务中被使用。作者没有说清楚本文和已有方法相比有什么动机和创新性。

RQ1似乎是本文的动机，然而HACMG和GT比较得出的结论不支持表2中的数据。直观上看，表2只展示了HACMG比GT使用了更多的历史信息。

RQ2提到HisRag使用BM25作为检索算法，原因是BM25实现了有效的结果。论文应该进行消融实验来支持这一点，因为应用的任务和提到的工作是不同的。

表2中GT行的B-Norm是1.0，std是0，文中没有解释原因。

图9中展示的例子表面上比其它方法（Codet5等）匹配了更多词（例如quay-enterprise）。然而从开发者的角度，这些方法表达的意思是一致的。尽管从实验角度，使用BLEU分数提高了生成效果，从实际角度，方法的有效性没有在这个指标中体现。从我的角度来看，使用这个例子来证明HisRag的效果不合适。

图10描述了实验相关的温度设置，但是没有任何关于此图的分析。图11没有相关的文本描述。

文章的格式问题，ASE官网提供了论文提交的指导：LaTeX用户必须使用\documentclass[sigconf,review,anonymous]{acmart} option，作者可能遗漏了review option导致每页的行号的缺失。很难指出表述问题的定位。图1尝试介绍cm，但是对于读者来说太复杂了。这里需要一个更简单的例子。表3中的文本Log_mnext和LogMnext不一致。

微小的错误：第1页的Abstract

“By comparing the results generated By HACMG” ->“By comparing the results generated by HACMG”

“Therefore, we propose a more effective method(HisRag)”->“Therefore, we propose a more effective method (HisRag)” (missing space, many occurrences in the paper)

Page 1-Introduction: “in both software development and maintenance processes,(i.e., implementing new features or fixing bugs).”->“in both software development and maintenance processes(i.e., implementing new features or fixing bugs).”

“Representation learning-based methods[16, 26, 34, 38, 42, 66]”->“Representation learning-based methods [16, 26, 34, 38, 42, 66]” (missing space, many occurrences in the paper)

Page 2-Background: “following commit message: Delete default release.scope and update doc..”->“following commit message: Delete default release.scope and update doc.” (redundant period)

“2.2 Large Language models” ->“2.2 Large Language Models”

“valuable corpora, i.e.Wikipedia, GitHub, arXiv”->“valuable corpora, i.e., Wikipedia, GitHub, arXiv” (missing comma)

Page 10: “Retrieval-Augmented Generation in Software Engineering tasks”->“Retrieval-Augmented Generation in Software Engineering Tasks”

B

缺点：

技术动机对于全文的ASE文章来说太平庸了

缺少一些重要的baselines

性能提升有限

缺少人类评估

贡献有限。作者总结这篇文章的贡献是新指标和新方法。然而新指标只是一个n-gram的precision指标，不是新的。HisRag只是简单地组合基于BM25的历史检索方法，没啥创意。RAG被用于多种软件工程任务，BM25也是最常用的检索相似example的方法[a]。此外，需要注意整个方法都是建立在HACMG上，只是已有的ASE文章的一部分。因此，技术动机对于一篇全文的ASE文章来说太有限了。

缺少重要的baselines。COME[b]和CCT5[c]最好的SOTA方法，但是没有被包含在baseline里面，造成评估的严谨。

缺少人类评估。用于度量文本相似度的指标没有准确评估生成消息的质量，CCT5中有提到。已有的工作会使用人类评估来缓解该问题，本文里缺少该部分。

4.1.2中的一些描述让人困惑。

1. 做了什么统计测验，p-value是多少
2. HP没有考虑GT，为什么HACMG的HP比CMG更高，能够说明使用cm历史的有效性
3. "A comparison between HACMG and GT reveals that, across 1-gram, 2-gram, 3-gram, and 4-gram, HPn-gram of HACMG consistently falls short of GT. This suggests that the utilization of historical information has not been optimized."根据表2，HACMG的HP分数一直比GT大。第二句的结论是如何基于这些结果得出的？
4. 表2中，GT的B-norm分数是1.0，应该是100.0

[a] Gao S, Wen X C, Gao C, et al. What makes good in-context demonstrations for code intelligence tasks with llms?[C]//2023 38^th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2023: 761-773.

[b] He Y, Wang L, Wang K, et al. COME: Commit Message Generation with Modification Embedding[C]//Proceedings of the 32^nd ACM SIGSOFT International Symposium on Software Testing and Analysis. 2023: 792-803.

[c] Lin B, Wang S, Liu Z, et al. Cct5: A code-change-oriented pre-trained model[C]//Proceedings of the 31^st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 2023: 1509-1521.

C

缺点：

解决方法太直接和简单了。只是减少了LLMs使用的commit历史的数量。本文中缺少方法的系统描述。

HisRag只适用commit历史的场景。

创新性：

本文的主要技术贡献是历史检索模块来提升HACMG。我认为这个设计的创新性太小了。此外，根据图11。top1的性能和top9的性能非常相似。这意味着使用最相关的commit是足够的。此外，提出的方法缺乏描述，除了图8.

作者在sec 1中提到在HACMG数据集上微调LLM很昂贵。HisRag不需要微调。这是HisRag相较于已有工作的重要优势吗？然而，从4.2.2的描述来看，没有baseline是微调的baseline。HisRag的性能是如何和微调方法比较的？如果展示计算资源的比较会很好。

D

Decision: REJECT

However, there are several limitations of this paper:

• 指标不能称为新指标
• 方法只是BM25，不够复杂
• RQ分析不清晰，RQ1中HACMG和GT的比较结果从表2中看不出来
• 缺少重要的基线，需要考虑COME、CCT5
• 性能提升有限。
• 缺少人类评估