LLM-Assisted Issue-Commit Linking: Making AI a Code Archaeologist

Forum topic · 小凯 · 2026-05-04

Summary

A zhichai.net forum post discusses the paper 'Think Harder and Don't Overlook Your Options: Revisiting Issue-Commit Linking with LLM-Assisted Retrieval' (arXiv 2605.00447, 2026) by Cole Morgan, Muhammad Asaduzzaman, Shaiful Chowdhurry, and Shaowei Wang. Issue-commit linking — finding which code commit fixes which bug report — is critical for software traceability, understanding change motivations, and knowledge transfer, yet repositories often contain thousands of issues and commits with no explicit links. Traditional heuristics like keyword matching and temporal proximity fail when vocabulary differs (e.g., 'login crash' vs 'fix authentication flow'). The paper proposes an LLM-assisted approach combining multi-source retrieval (text similarity, code-diff semantics, temporal signals, developer and file-path overlap), LLM-based re-ranking of retrieved candidates, chain-of-thought reasoning ('Think Harder'), and broad candidate consideration ('Don't Overlook Your Options'). The post argues LLMs' joint understanding of text and code semantics upgrades linkers from keyword matchers to 'code archaeologists.'

Overview

> 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 who sees an issue: "Login page crashes on some browsers." You want to know whether it was fixed, by which commit, and how — but the repository has 10,000+ issues, 50,000+ commits, and no explicit issue-commit links. Searching manually is like finding a needle in a haystack.

Why Automatic Linking Matters

Software traceability: requirement → design → code → test, forming a complete development chain for auditing and maintenance.
Understanding change motivations: why was this code changed, and because of which issue?
Knowledge transfer: newcomers can quickly understand history ("this odd design fixed that bug"), reducing duplicated work.

Limitations of existing methods: heuristics (keyword matching, temporal proximity) have low precision and even lower recall, while deep learning approaches require large labeled datasets.

The LLM-Assisted Approach

Core insight: LLMs understand both text semantics and code semantics, and this dual understanding makes them excel at issue-commit linking.

1. Multi-source retrieval — beyond text similarity, the approach uses code-change semantics (diff meaning), temporal proximity, developer associations, and file-path matching.

2. LLM re-ranking — traditional retrieval first produces candidate commits; an LLM then ranks them by understanding the deeper connection between issue descriptions and code changes.

3. Don't Overlook Your Options — traditional methods only consider the few most similar candidates, but the correct commit may rank low; LLMs can "rediscover" overlooked options.

4. Think Harder — 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 LLM reads not only surface keywords but the essence of the problem and the intent of the code.

Why LLMs Beat Traditional Methods

| Traditional | Problem | |---|---| | Keyword matching | "login crash" vs "fix authentication flow" — no keyword overlap, but semantically related | | Temporal proximity | Fixes may be split across commits or delayed |

LLM advantages:

Semantic understanding: linking terms even without shared keywords.
Code understanding: reading diffs to infer what problem a change solves.
Multi-step reasoning: "This issue is about X; this commit modifies Y; Y is part of X; so they are related."

Key Takeaway

Finding commits with matching keywords is not the same as finding the commit that fixed the bug. True linking requires understanding what the problem is, what the change intends, and whether both address the same issue. Questions to ask of your own traceability approach:

1. Does my linking 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 change intent?

Software traceability is not just a technical problem — it is a comprehension problem. The best link is not the most exact match, but the deepest understanding.