EasyLink: Issue–Commit Linking Approach

• EasyLink is an issue–commit linking approach that automatically connects issue reports to their fix commits using a two-stage pipeline of dense retrieval and LLM-based reranking.
• It utilizes dense text embeddings from MiniLM-L6-v2 and FAISS for efficient candidate selection under a realistic one-year temporal window to capture heavy-tailed candidate distributions.
• Subsequent studies use EasyLink both as a baseline method and dataset, reexamining its temporal window and ranking assumptions while comparing against alternative retrieval and reranking techniques.

Searching arXiv for papers on EasyLink to ground the article in current literature. arxiv_search query: EasyLink issue commit linking Huang reranking arxiv_search query: "Think Harder and Don't Overlook Your Options: Revisiting Issue-Commit Linking with LLM-Assisted Retrieval" arxiv_search query: "Back to the Basics: Rethinking Issue-Commit Linking with LLM-Assisted Retrieval" EasyLink is an issue–commit linking approach introduced by Huang et al. for automatically connecting issue reports to the commits that resolve them. In its original formulation, it combines a vector database over dense text embeddings with a LLM reranker, and it is evaluated under a Realistic Distribution Setting (RDS) designed to approximate the heavy-tailed candidate distributions encountered in active repositories. In later work, EasyLink is also used as the name of a prior baseline and of an associated dataset/benchmark, and its temporal window, retrieval design, and LLM-based reranking assumptions are re-examined against broader retrieval and reranking alternatives (Huang et al., 12 Jul 2025, Morgan et al., 1 May 2026).

1. Definition and Conceptual Scope

EasyLink addresses the issue–commit linking problem, in which an issue is treated as a query and the task is to identify the commit or commits that fixed it. The original motivation is software traceability and provenance, with downstream relevance to security tasks such as identifying vulnerability-fixing commits and vulnerability-contributing commits, as well as impact analysis, regression testing, and project management (Huang et al., 12 Jul 2025).

In the original paper, EasyLink is a two-stage retrieval architecture. First, commit messages and issue texts are embedded and indexed in a vector database. Second, a LLM reranks the top retrieved commits to bridge the semantic gap between issue descriptions and commit messages. The method is explicitly zero-shot at the reranking stage: the LLM is prompted with the issue text and candidate commit messages and returns an ordered list of commit IDs rather than calibrated scores (Huang et al., 12 Jul 2025).

A later revisit uses the term in two related senses. It refers to EasyLink both as a prior technique by Huang et al. and as the “EasyLink dataset” released with that technique. In that later study, EasyLink itself is not re-implemented as an end-to-end pipeline; instead, its one-year temporal window, retrieval-plus-reranking architecture, LLM prompting style, and evaluation metrics are adopted as a conceptual baseline for systematic comparison against alternative retrievers and rerankers (Morgan et al., 1 May 2026).

2. Problem Formulation and Realistic Evaluation Setting

A central claim of EasyLink is that prior evaluations often make issue–commit linking artificially easy. The original study identifies three recurring artifacts: narrow candidate windows, dependence on issue close time, and unrealistic true/false link distributions. Earlier work often restricted candidate commits to windows such as $\pm 7$ days around issue lifecycle events. EasyLink reports that only $59\%$ of issues have their fix commit within $7$ days of issue creation, whereas about $97\%$ fall within one year. This motivates using a one-year window after issue creation as a more realistic but still bounded candidate space (Huang et al., 12 Jul 2025).

Under RDS, candidate generation is defined by a simple temporal condition. Let $I_i$ be an issue and $C_j$ a commit. Then $C_j$ is a candidate for $I_i$ if

$$\begin{aligned} \text{is\_candidate}(I_i, C_j) &= \text{created}(I_i) \leq \text{committed}(C_j) \ &\land \; \text{committed}(C_j) \leq \text{created}(I_i) + \epsilon, \ \epsilon &= \text{one year.} \end{aligned}$$

For each issue, all commits in that interval except the known fix commit are treated as false links; thus the number of false candidates depends on actual repository activity rather than on a fixed synthetic count (Huang et al., 12 Jul 2025).

The RDS benchmark in the original EasyLink paper is built from 20 open-source projects. It contains 9,319 unique issue IDs, and the average number of false links per issue is about 1,530, with project-level averages ranging from about 179 to about 6,097. The study also notes that $17\%$ of issues are fixed by multiple commits. This distribution is substantially harsher than settings with a fixed 99 false commits per issue, and it is specifically intended to expose interference from “plausible yet unrelated commits” that share lexical or topical overlap with the issue (Huang et al., 12 Jul 2025).

3. Architecture and Technical Operation

EasyLink’s retrieval stage uses a dense embedding model and exact vector search. The embedding model is all-MiniLM-L6-v2 from Sentence-Transformers, with output dimension $59\%$0. For an input text $59\%$1,

$59\%$2

Commit embeddings are computed from commit messages; issue embeddings are computed from the concatenation of issue summary and description. Commit IDs and issue IDs are stored as metadata alongside embeddings (Huang et al., 12 Jul 2025).

The vector database is FAISS, configured for exact search using squared $59\%$3 distance. For a query embedding $59\%$4 and commit embedding $59\%$5,

$59\%$6

FAISS returns the top-$59\%$7 nearest commits, with smaller distance indicating higher similarity. In the default configuration, EasyLink uses $59\%$8 candidates for reranking (Huang et al., 12 Jul 2025).

The second stage is LLM-assisted reranking. The input to the LLM consists of the issue text and, for each of the top-$59\%$9 retrieved commits, the commit ID and commit message. The prompt specifies the task as identifying which commit or commits fix the issue and requires the output to be a reranked list of commit IDs. The model used in the original study is GPT-4o (gpt-4o-2024-11-20) with temperature $7$0, one sample per query, and no fine-tuning. If the output cannot be parsed, which occurs in approximately $7$1 of cases, the system falls back to the original vector database ranking (Huang et al., 12 Jul 2025).

The later revisit preserves this architectural decomposition but generalizes both stages. It explicitly characterizes EasyLink as a pipeline of temporal candidate selection, IR retrieval, and LLM reranking. It then varies the retrieval component across BM25, BM25L, SBERT-Semantic Search, ANNOY, HNSW, and LSH, and varies the reranker across traditional machine learning models, a cross-encoder, and multiple LLMs, while keeping EasyLink’s prompting format as the reference behavior for LLM-based reranking (Morgan et al., 1 May 2026).

4. Datasets, Metrics, and Reported Performance

The original EasyLink paper evaluates the method on a 20-project benchmark under RDS. On that benchmark, EasyLink reports an average Precision@1 of $7$2, whereas the vector database stage alone reaches $7$3, VSM reaches $7$4, and EALink reaches $7$5. Mean Reciprocal Rank is $7$6 for EasyLink, compared with $7$7 for the vector database alone, $7$8 for VSM, and $7$9 for EALink. NDCG@10 is $97\%$0 for EasyLink, versus $97\%$1 for the vector database stage and $97\%$2 for EALink. Because reranking changes only the order within the retrieved top-$97\%$3, P@10, Hit@10, and Recall@10 are identical for the vector database and EasyLink (Huang et al., 12 Jul 2025).

System	P@1	MRR
EALink	14.43	20.21
VSM	46.59	55.10
Vector DB	64.03	71.59
EasyLink	75.91	79.92

The same study also validates EasyLink on EALink’s original 6-project, 99-false-link setting. There, EALink attains P@1 of $97\%$4, the vector database alone attains $97\%$5, and EasyLink attains $97\%$6. The paper reports that EasyLink’s improvements over EALink are statistically significant according to Mann–Whitney U tests with $97\%$7 and large effect sizes with Cohen’s $97\%$8 for all metrics (Huang et al., 12 Jul 2025).

Ablation results in the original paper emphasize the importance of the retrieval stage. MiniLM yields P@1 of $97\%$9 with test time $I_i$0 hours; MPNet yields $I_i$1 with $I_i$2 hours; OpenAI text-embedding-ada-002 yields $I_i$3 with $I_i$4 hours. The paper interprets MiniLM as a favorable balance of performance and speed. Varying the reranking depth over $I_i$5 shows that larger $I_i$6 generally improves P@1, MRR, and NDCG@1, but gains beyond $I_i$7 are small relative to increased token usage and test time, so $I_i$8 is selected as the preferred trade-off (Huang et al., 12 Jul 2025).

The later paper refers to the “EasyLink dataset” in a different sense: 20 open-source projects, 159,592 true links, 54,922 issues, and 346,501 commits from 2003–2020. It reuses that dataset and contrasts its temporal characteristics with BTLink and Apache datasets. For consistency with EasyLink, it uses the same metrics: Precision@K, Hit@K, Recall@K, NDCG@K, and MRR. The definitions used there are

$I_i$9

$C_j$0

$C_j$1

$C_j$2

$C_j$3

These metrics are applied to both retrieval evaluation and reranking evaluation in the revisit (Morgan et al., 1 May 2026).

5. Reassessment of EasyLink in Later Work

The later study confirms one of EasyLink’s central observations but also narrows its scope. On the EasyLink dataset, a one-year window after issue creation still captures approximately $C_j$4 of true links. However, the same heuristic captures only $C_j$5 of true links on the BTLink dataset and $C_j$6 on the Apache dataset. The same analysis finds that a substantial number of fix commits occur after issue closure—$C_j$7 in the EasyLink dataset, $C_j$8 in BTLink, and $C_j$9 in Apache—whereas commits before issue creation are rare. On that basis, the authors propose a hybrid window consisting of one year after issue creation plus 30 days before and after issue closure; this window captures more than $C_j$0 of true links across all three datasets (Morgan et al., 1 May 2026).

The retrieval stage is also re-evaluated. On the EasyLink dataset at $C_j$1, SBERT-SS reports P@1 $C_j$2, R@1 $C_j$3, R@10 $C_j$4, MRR@10 $C_j$5, and NDCG@10 $C_j$6. ANNOY reports P@1 $C_j$7, R@1 $C_j$8, R@10 $C_j$9, and MRR@10 $I_i$0. BM25 reports P@1 $I_i$1, R@1 $I_i$2, R@10 $I_i$3, and MRR@10 $I_i$4. Reciprocal Rank Fusion of BM25 and SBERT-SS reports P@1 $I_i$5, R@1 $I_i$6, R@10 $I_i$7, and MRR@10 $I_i$8. The reported pattern is that dense retrieval significantly outperforms sparse retrieval, while dense-plus-sparse fusion can improve recall (Morgan et al., 1 May 2026).

The reranking stage receives an even sharper reassessment. Using the EasyLink-style prompt, the later study compares GPT-5.1, Qwen3-32B, Llama-3.1-8B, and Gemma-7B against RCLinker, FRLink, Hybrid-Linker, BTLink, and a cross-encoder. On the EasyLink dataset, RCLinker reports P@1 $I_i$9, R@1 $$\begin{aligned} \text{is\_candidate}(I_i, C_j) &= \text{created}(I_i) \leq \text{committed}(C_j) \ &\land \; \text{committed}(C_j) \leq \text{created}(I_i) + \epsilon, \ \epsilon &= \text{one year.} \end{aligned}$$0, MRR@10 $$\begin{aligned} \text{is\_candidate}(I_i, C_j) &= \text{created}(I_i) \leq \text{committed}(C_j) \ &\land \; \text{committed}(C_j) \leq \text{created}(I_i) + \epsilon, \ \epsilon &= \text{one year.} \end{aligned}$$1, and NDCG@10 $$\begin{aligned} \text{is\_candidate}(I_i, C_j) &= \text{created}(I_i) \leq \text{committed}(C_j) \ &\land \; \text{committed}(C_j) \leq \text{created}(I_i) + \epsilon, \ \epsilon &= \text{one year.} \end{aligned}$$2. GPT-5.1 reports P@1 $$\begin{aligned} \text{is\_candidate}(I_i, C_j) &= \text{created}(I_i) \leq \text{committed}(C_j) \ &\land \; \text{committed}(C_j) \leq \text{created}(I_i) + \epsilon, \ \epsilon &= \text{one year.} \end{aligned}$$3, R@1 $$\begin{aligned} \text{is\_candidate}(I_i, C_j) &= \text{created}(I_i) \leq \text{committed}(C_j) \ &\land \; \text{committed}(C_j) \leq \text{created}(I_i) + \epsilon, \ \epsilon &= \text{one year.} \end{aligned}$$4, MRR@10 $$\begin{aligned} \text{is\_candidate}(I_i, C_j) &= \text{created}(I_i) \leq \text{committed}(C_j) \ &\land \; \text{committed}(C_j) \leq \text{created}(I_i) + \epsilon, \ \epsilon &= \text{one year.} \end{aligned}$$5, and NDCG@10 $$\begin{aligned} \text{is\_candidate}(I_i, C_j) &= \text{created}(I_i) \leq \text{committed}(C_j) \ &\land \; \text{committed}(C_j) \leq \text{created}(I_i) + \epsilon, \ \epsilon &= \text{one year.} \end{aligned}$$6. Qwen3-32B reports P@1 $$\begin{aligned} \text{is\_candidate}(I_i, C_j) &= \text{created}(I_i) \leq \text{committed}(C_j) \ &\land \; \text{committed}(C_j) \leq \text{created}(I_i) + \epsilon, \ \epsilon &= \text{one year.} \end{aligned}$$7, R@1 $$\begin{aligned} \text{is\_candidate}(I_i, C_j) &= \text{created}(I_i) \leq \text{committed}(C_j) \ &\land \; \text{committed}(C_j) \leq \text{created}(I_i) + \epsilon, \ \epsilon &= \text{one year.} \end{aligned}$$8, and MRR@10 $$\begin{aligned} \text{is\_candidate}(I_i, C_j) &= \text{created}(I_i) \leq \text{committed}(C_j) \ &\land \; \text{committed}(C_j) \leq \text{created}(I_i) + \epsilon, \ \epsilon &= \text{one year.} \end{aligned}$$9. The cross-encoder reports P@1 $17\%$0, R@1 $17\%$1, and MRR@10 $17\%$2. The paper concludes that RCLinker, a random forest over textual and metadata features, outperforms GPT-5.1 and other LLMs on P@1 and slightly on MRR across all datasets, and that a small cross-encoder is close to the larger LLMs without their API cost profile (Morgan et al., 1 May 2026).

6. Limitations, Misconceptions, and Practical Significance

One recurring misconception is that the main innovation in EasyLink is the use of an LLM and that LLM reranking is therefore the dominant source of performance. The original paper does report a substantial gain from reranking on top of dense retrieval: under RDS, the vector database stage alone attains P@1 of $17\%$3, and EasyLink increases this to $17\%$4. However, the later reassessment suggests that the retrieval stage and the candidate distribution are at least as consequential as the reranker choice, and that a well-designed classical reranker can exceed the performance of the LLM-based stage in the same retrieval-plus-reranking framework (Huang et al., 12 Jul 2025, Morgan et al., 1 May 2026).

A second misconception is that EasyLink’s one-year post-creation temporal window is universally adequate. The original EasyLink study justifies the window on its own benchmark by showing that about $17\%$5 of fix commits occur within one year of issue creation. The later study confirms that value on the EasyLink dataset but shows that the heuristic is dataset-specific and not fully robust across BTLink and Apache. This suggests that EasyLink’s temporal modeling was an important correction to unrealistically narrow windows, but not the final word on temporal candidate generation (Huang et al., 12 Jul 2025, Morgan et al., 1 May 2026).

The computational implications are also nontrivial. In the original paper, EasyLink requires no task-specific training, and its total testing time is $17\%$6 hours, essentially matching EALink’s $17\%$7 hours while delivering much higher accuracy. The vector database alone needs $17\%$8 hours and no training. The later study quantifies LLM API cost more directly: evaluating GPT-5.1 over 41,203 test issues costs \$17\%$90.004 per issue, under discounted batch API pricing. By contrast, RCLinker and the cross-encoder can be trained in under a few hours on modest hardware, and inference takes minutes with no per-query API cost (Huang et al., 12 Jul 2025, Morgan et al., 1 May 2026).

Taken together, the literature positions EasyLink less as a monolithic best-performing solver than as a historically important retrieval-based template for realistic issue–commit linking. Its durable contributions are the insistence on realistic candidate distributions, the use of strong retrieval as the backbone of the pipeline, and the framing of LLMs as rerankers over a narrowed candidate set. The later evidence suggests that these architectural ideas remain useful even when the original one-year window and LLM reranker are replaced by a hybrid temporal window, denser retrieval, or less expensive reranking models (Huang et al., 12 Jul 2025, Morgan et al., 1 May 2026).