> Paper: Think Harder and Don't Overlook Your Options: Revisiting Issue-Commit Linking with LLM-Assisted Retrieval > Authors: Cole Morgan, Muhammad Asaduzzaman, Shaiful Chowdhurry, Shaowei Wang > arXiv: 2605.00447 | 2026-04-29
The "Who Fixed This Bug?" Problem
Imagine you are a new developer on a project. You see an issue: "The login page crashes on certain browsers." You want to know: has it been fixed? Which commit fixed it? How?
But the repository contains 10,000+ issues and 50,000+ commits with no explicit issue-commit links. Finding the answer manually is like searching for a needle in a haystack.
Why Issue-Commit Linking Matters
- Software traceability: requirements → design → code → tests, forming a complete development chain for auditing and maintenance.
- Understanding change motivation: why was this code changed, and for which issue or bug?
- Knowledge transfer: newcomers quickly learn that "this odd design exists to fix that problem," reducing duplicated work.
- Heuristics (keyword matching, temporal proximity): low precision and even lower recall.
- Deep learning approaches: require large labeled datasets.
- Semantic understanding: linking "login crash" to "authentication flow" despite different vocabulary.
- Code understanding: reading diffs to infer what problem a change solves and matching it to the issue.
- Multi-step reasoning: "the issue is about X; the commit modifies Y; Y is part of X; therefore they are related."
Limitations of existing methods:
LLM-Assisted Retrieval: The Paper's Approach
Core insight: LLMs understand both natural-language semantics and code semantics — a dual understanding that makes them strong at issue-commit linking.
1. Multi-signal retrieval — beyond text similarity, the approach uses code-change semantics (the diff), temporal proximity, developer association, and file-path matching.
2. LLM re-ranking — traditional retrieval first produces candidate commits; an LLM then performs fine-grained re-ranking by understanding the deeper connection between the issue description and the code change.
3. Don't Overlook Your Options — the paper's title: correct commits are often ranked low by traditional methods. Using a wider candidate pool lets the LLM "rediscover" neglected options.
4. Think Harder — the LLM applies chain-of-thought reasoning: "This issue describes X... this commit changes Y... are they related, and why?" Deep reasoning beats shallow matching.
Like an experienced code archaeologist, the model looks beyond surface keywords to understand the nature of the problem and the intent of the change.
Why LLMs Beat Traditional Methods
Keyword matching fails: an issue says "login crash"; the commit says "fix authentication flow." Keywords don't overlap, but the semantics do.
Temporal proximity is fragile: fixes may be split across multiple commits or delayed, so proximity assumptions break down.
LLM strengths:
Takeaway
> Finding a commit that shares keywords is not the same as finding the commit that fixes the problem. Real linking requires understanding: what is the essence of the issue? What is the intent of the change? Are they solving the same problem?
Questions worth asking if you work on traceability or code understanding: 1. Does my linking method rely only on surface features? 2. Could semantic understanding improve accuracy? 3. Am I considering all candidates, or only the top-ranked ones? 4. Could LLM reasoning help interpret the intent of code changes?
When an LLM understands issue-commit relationships at the semantic level, it upgrades from a "keyword matcher" to a "code archaeologist." In the history of a codebase, the best link is not the most exact match — it's the deepest understanding.
*Reference: arXiv:2605.00447*