LastMerge: Generic Code Merge Tool

• LastMerge is a language-agnostic structured merge tool that performs three-way merges by parsing Tree-sitter generated concrete syntax trees instead of unstructured line sequences.
• It employs a thin configuration interface to specify node ordering and unique identifiers, enabling sophisticated matching through dynamic and linear programming techniques.
• Empirical evaluations demonstrate that LastMerge delivers comparable runtime performance to language-specific merge tools while exhibiting roughly a 10% discrepancy in conflict detection rates.

Searching arXiv for the cited paper and closely related merge-tool papers to ground the article. {"query":"arXiv (Duarte et al., 25 Jul 2025) LastMerge A language-agnostic structured tool for code integration"} to=arxiv_search เติมเงินไทยฟรี 尚度=1 code: {"query":"(Duarte et al., 25 Jul 2025)"} to=arxiv_search 天天中彩票在哪cript code: {"query":"LastMerge"} to=search_arxiv 天天中彩票充值 code: {"query":"(Duarte et al., 25 Jul 2025)"} LastMerge is a language-agnostic structured merge tool for code integration that performs three-way merge over generic trees derived from Tree-sitter parses rather than over unstructured sequences of lines or a language-specific AST. Its central objective is to improve merge accuracy across many programming languages through a reusable merge engine and a thin configuration interface that specifies only language-specific structural information, such as node identities and whether child order is semantically relevant. In the reported Java evaluation, LastMerge is positioned as a generic counterpart to jDime, while Mergiraf is used as a generic counterpart to Spork; the resulting study finds no evidence that generic structured merge significantly impacts merge accuracy and reports runtime performance comparable to state-of-the-art language-specific implementations (Duarte et al., 25 Jul 2025).

1. Problem setting and motivation

Collaborative software development routinely merges divergent branches through a version control system such as Git. The default mechanism in most VCSs is an unstructured, line-based three-way merge, exemplified by diff3. Such tools compare files only as sequences of lines and therefore ignore language syntax and semantics (Duarte et al., 25 Jul 2025).

The principal consequences are spurious conflicts and missed conflicts. A spurious conflict, or false positive, arises when harmless independent edits affect the same textual region. The paper’s illustrative Java example is a method whose modifiers are changed independently on two branches:

$(\text{base},\text{right})$4

A line-based merge treats this as “the same line changed twice” and raises a conflict, even though public static void debit(int amount) is a valid integrated result (Duarte et al., 25 Jul 2025). Conversely, a missed conflict, or false negative, occurs when a true semantic conflict does not surface as a textual conflict and therefore passes through the merge process undetected.

Structured merge addresses this limitation by parsing revisions into an Abstract Syntax Tree or similar tree, performing tree differencing and matching, and merging at the level of language constructs such as methods, fields, statements, and expressions. Prior work cited in the paper shows that structured merge significantly improves merge accuracy over unstructured merge. The paper attributes the low industrial uptake of such tools to language specificity, implementation cost, maintenance burden as languages evolve, and the limited number of languages for which bespoke structured merge tools exist (Duarte et al., 25 Jul 2025).

LastMerge is proposed to fill this gap. It is designed as a single structured merge engine that can be reused across languages, with per-language support provided through a thin, low-effort configuration interface rather than by re-implementing the merge algorithm for each language.

2. Generic structured merge model

LastMerge is described as a generic structured merge engine operating on generic trees and powered by Tree-sitter, an extensible parser framework with grammars for 350+ languages. In this design, “language-agnostic” means that the core parsing, matching, and merging algorithms are defined over generic tree nodes rather than being specialized for Java, C#, Python, or another specific language. “Generic structured merge” correspondingly denotes a tree-based merge implemented over a common tree abstraction plus configuration, rather than over a hard-coded AST representation (Duarte et al., 25 Jul 2025).

The underlying representation uses Concrete Syntax Trees rather than ASTs. This preserves syntax and lexical elements, while still allowing structured matching and merge. Each node is either a terminal or a nonterminal. Nonterminals have a syntactic kind, a list of children, a flag indicating whether their children are ordered or unordered, and an optional identifier string. This combination is sufficient for LastMerge’s generic matching and merging algorithms (Duarte et al., 25 Jul 2025).

The thin configuration interface is the mechanism by which a new language is supported. A language integrator uses a Tree-sitter grammar and provides configuration that specifies which node kinds should be treated as unordered, how to extract per-sibling unique identifiers for relevant nodes, and optionally how to post-process the parsed tree through parsing handlers. For Java, the paper gives examples such as treating lists of field declarations, import declarations, and modifier lists as unordered, while preserving ordered behavior for statement sequences or parameter lists when order matters (Duarte et al., 25 Jul 2025).

Identifier extraction is expressed through Tree-sitter queries. The paper gives a conceptual example for a Java class declaration:

$(\text{base},\text{right})$5

This kind of query lets LastMerge assign an identifier such as a class name, method signature, or field name to a node, enabling structurally meaningful matching. Optional parsing handlers can further restructure the CST for better merge behavior; the paper’s example is grouping all import declarations under a single nonterminal marked unordered so that import reordering matches cleanly. The configuration can also specify “stop parsing here” cutoffs to emulate semistructured merge by treating selected subtrees as textual leaves (Duarte et al., 25 Jul 2025).

3. Parsing, matching, and merge procedure

LastMerge’s workflow has three stages: parsing, matching, and merging. During parsing, Tree-sitter is used to parse the base, left, and right revisions into CSTs. The parser then applies node marking for ordered versus unordered children, identifier extraction via Tree-sitter queries, and any configured parsing handlers. The resulting generic tree nodes carry the structural information needed by the later phases (Duarte et al., 25 Jul 2025).

The matching phase is adapted from jDime’s algorithms and generalized to the generic tree interface. LastMerge computes pairwise matchings for $(\text{base},\text{left})$, $(\text{base},\text{right})$, and $(\text{left},\text{right})$. Matching is constrained by node category and metadata: terminals only match terminals, nonterminals only match nonterminals, node kinds must agree, identifiers must coincide when present, and terminal values must be identical. For nonterminals, once roots are considered a match, their children are recursively matched in a level-wise manner (Duarte et al., 25 Jul 2025).

Different algorithms are used depending on whether children are ordered or unordered. Ordered children are matched using Yang’s algorithm for tree differencing, with dynamic programming in $O(n^2)$ time to compute a maximum matching between child sequences. Unordered children are matched using a linear-programming-based maximum matching in $O(n^3)$ time, following jDime’s approach. The paper notes that Yang’s recursion is not printed explicitly, but characterizes it as a dynamic-programming matrix over child indices that accumulates the best matching between prefixes of the sequences (Duarte et al., 25 Jul 2025).

The merge stage traverses the three trees in depth-first fashion, guided by the pairwise matchings, and constructs the final merged tree. The algorithm decides whether a node should be retained from the left, right, or base revision, or whether non-conflicting modifications from both sides can be integrated. Conflict detection covers standard patterns such as modify/modify, modify/delete or delete/edit, and insert/insert conflicts. For unordered nodes, LastMerge can reorder children to reconcile concurrent edits, which is relevant for constructs such as modifiers or import declarations. For ordered nodes, sequence order is preserved, and conflicting changes in the same structural position are reported. The final merged tree is then serialized back to text, with the paper emphasizing correctness and conflict minimization rather than pretty-printing (Duarte et al., 25 Jul 2025).

4. Relation to jDime, Spork, and Mergiraf

The evaluation is explicitly framed around two tool pairs. jDime and Spork are language-specific structured merge tools for Java, whereas LastMerge and Mergiraf are their respective generic counterparts configured for Java. jDime uses Java ASTs from JastAddJ together with language-specific matching and merging algorithms, and its original design includes auto-tuning between structured and unstructured merge. Spork is a more recent Java structured merge tool that uses GumTree for fine-grained tree differencing and emphasizes formatting preservation, attempting to reuse original source fragments so that the merged file retains the original formatting in more than 90% of cases (Duarte et al., 25 Jul 2025).

LastMerge is presented as a generic version of jDime: it retains the same family of algorithms, notably Yang for ordered matching and linear programming for unordered matching, but runs over a language-independent CST representation produced by Tree-sitter. Mergiraf is presented as a generic version of Spork: it also uses Tree-sitter and a generic tree representation, but preserves Spork’s high-level merge strategy while adding some refinements (Duarte et al., 25 Jul 2025).

Several architectural differences discussed in the paper are not attributed to genericity itself. Mergiraf uses auto-tuning by attempting unstructured merge first and invoking structured merge only when conflicts arise. When structured merge is used, it builds “fictional” trees around conflicts discovered by line-based merge so that many matches can be pre-assigned, and it uses GumTree for the remaining matchings. Mergiraf also extends Spork’s algorithm with explicit delete/edit detection. The paper treats these as design choices rather than intrinsic consequences of genericity (Duarte et al., 25 Jul 2025).

The empirical disagreement rates between language-specific tools and their generic counterparts are summarized as follows:

Pair	Agreement on conflict existence	Disagreement
jDime vs LastMerge	4,909 scenarios (92.5%)	400 scenarios (7.53%)
Spork vs Mergiraf	4,697 scenarios (88.7%)	601 scenarios (12.22%)

These rates amount to roughly a 10% difference rate between specific and generic pairs. The paper’s deeper analysis attributes most of the observed differences to configuration and implementation choices rather than to the use of a generic tree architecture (Duarte et al., 25 Jul 2025).

5. Evaluation methodology and empirical findings

The evaluation uses the dataset from Schesch et al. (ASE 2024). The initial dataset contains 5,983 merge scenarios from 1,116 open-source Java projects, mostly from GitHub’s Greatest Hits and Reaper-curated engineered projects. These scenarios are real merge commits represented as quadruples of merge commit, two parents, and base, and the selected projects have non-trivial test suites that pass on both parents. After filtering out unavailable repositories, scenarios without mutually modified files, and scenarios in which any evaluated tool crashed, the final sample contains 5,229 merge scenarios and 13,675 mutually modified files (Duarte et al., 25 Jul 2025).

Rather than estimate absolute false positives and false negatives directly, the study uses relative metrics between tool pairs: added false positives (aFPs) and added false negatives (aFNs). For a pair $(A,B)$, an aFP for $A$ occurs when $A$ reports a conflict, $B$ does not, and $B$’s conflict-free output is deemed correct. An aFN for $(\text{base},\text{right})$0 occurs when $(\text{base},\text{right})$1 reports no conflict, $(\text{base},\text{right})$2 does, and $(\text{base},\text{right})$3’s output is deemed wrong. Only scenarios in which the tools disagree on whether a conflict exists are considered. Correctness is assessed first through syntactic equivalence with the repository merge commit, with formatting normalized by re-running jDime or Spork on LastMerge or Mergiraf outputs, and then through the project’s test suite if syntactic equivalence is not established (Duarte et al., 25 Jul 2025).

For jDime versus LastMerge, the study reports the following counts:

Situation	jDime	LastMerge
Added false positives (aFPs)	153	130
Added false negatives (aFNs)	29	85

This means that LastMerge reports 15% fewer aFPs than jDime, but about three times as many aFNs in the disagreement set. The paper notes that the 56 extra aFNs correspond to approximately 1.1% of all 5,229 scenarios and about 14% of disagreement scenarios. The manual analysis attributes these differences primarily to matching configuration and other implementation details, including how method and constructor identity is defined, how ordered versus unordered children are chosen, and how specific syntactic elements such as type arguments or throws clauses are handled (Duarte et al., 25 Jul 2025).

The paper gives several concrete examples. jDime can produce aFPs because it fails to assign unique identifiers to field declarations and instead uses purely structural matching; two added fields with different names may then be partially matched, generating a spurious insert/insert conflict. LastMerge avoids this by using field names as identifiers. Conversely, LastMerge can produce aFPs in method-renaming scenarios because it matches methods only when signatures are identical; if one side changes a method signature and the other changes only the method body, LastMerge may fail to match them and report a modify/delete conflict, whereas jDime’s more flexible structural matching can align them. On the aFN side, the paper notes that jDime may match overloaded constructors solely by name, ignoring parameter lists, and can therefore miss a real delete/edit conflict that leads to compilation errors; LastMerge, by matching constructors by full signature, detects the conflict (Duarte et al., 25 Jul 2025).

For Spork versus Mergiraf, the reported counts are:

Situation	Spork	Mergiraf
Added false positives (aFPs)	150	290
Added false negatives (aFNs)	107	62

Mergiraf therefore has almost twice as many aFPs as Spork but 42% fewer aFNs. According to the manual analysis, two design choices dominate this result. First, Mergiraf’s auto-tuning can reduce some false positives because it accepts an unstructured merge result when that result is clean; the paper reports that in 4 out of 5 sampled cases where Spork had aFPs, Mergiraf used unstructured merge successfully while Spork’s structured-only approach raised spurious conflicts due to imperfect matching. Second, Mergiraf extends the merge algorithm to detect delete/edit conflicts by recording deletions and checking after construction of the merged tree whether a deleted node was modified on the other side. This reduces aFNs but also raises conflicts in some cases where the delete/edit change might not cause semantic issues, making Mergiraf more conservative in relative comparisons (Duarte et al., 25 Jul 2025).

Runtime is measured by running each tool 10 times sequentially on each scenario, discarding the first run as warm-up, averaging the remaining 9 runs, aggregating file times to scenario times, and comparing distributions on a log scale. Figure 1 in the paper is summarized as showing that LastMerge and Mergiraf are significantly faster than jDime and Spork, roughly by an order of magnitude on average. The paper attributes this to implementation language, with LastMerge and Mergiraf written in Rust and jDime and Spork in Java, to auto-tuning in Mergiraf, and to other implementation optimizations. The authors further note that even under a conservative assumption of a 10× performance penalty when porting from Rust to Java, LastMerge would still be comparable to state-of-the-art Java tools and would handle about 80.2% of scenarios in under three seconds (Duarte et al., 25 Jul 2025).

6. Configuration burden, limitations, and implications

Supporting a new language in LastMerge requires a Tree-sitter grammar, configuration for ordered and unordered node kinds, identifier extraction rules expressed through Tree-sitter queries, and optionally parsing handlers that reorganize the tree to better reflect merge-relevant structure. The paper characterizes this as a deliberately small interface relative to the effort of building and maintaining a full language-specific structured merge tool. It also notes that the same mechanism can emulate semistructured tools such as FSTMerge, s3m, and Sesame by using “stop parsing here” boundaries that treat selected subtrees as textual chunks (Duarte et al., 25 Jul 2025).

At the same time, configuration quality is presented as a substantive source of error. Incorrect ordered or unordered marking, weak identifier definitions, or insufficient parsing handlers can induce both false positives and false negatives. The paper’s empirical analysis repeatedly links observed differences between specific and generic tools to such choices rather than to genericity itself. This includes whether method identity is based on full signature, how overloaded constructors are distinguished, whether type arguments are treated as ordered or unordered, and whether imports are normalized into a single unordered group (Duarte et al., 25 Jul 2025).

The paper also identifies limitations and threats to validity. Repository merge commits and test suites are used as an approximation to conflict ground truth, but developers may have merged faulty code and corrected it later, and test suites may be incomplete. Manual analysis of aFP and aFN causes is subjective, even though findings were cross-checked among the authors. The evaluation is restricted to Java projects from GitHub, so the study does not by itself establish equivalent behavior for other languages. Although LastMerge and Mergiraf are generic by design, the experiments configure them only for Java because jDime and Spork are Java-only baselines. The paper therefore states that broader generalization requires further work in additional languages (Duarte et al., 25 Jul 2025).

Within those bounds, the reported evidence does not support the claim that generic structured merge inherently incurs an accuracy or performance penalty. The observed difference rate between language-specific tools and their generic counterparts is approximately 10%, and the paper attributes most of those differences to configuration and implementation details that could be changed without abandoning a language-agnostic architecture. This suggests that a single structured merge engine, configured through Tree-sitter grammars and lightweight language metadata, can plausibly replace language-specific tools in settings where multi-language repository coverage and maintainability are important (Duarte et al., 25 Jul 2025).

The prospective impact identified in the paper is correspondingly practical rather than theoretical. Organizations could adopt one structured merge engine and configure it for many languages using existing Tree-sitter grammars. The anticipated benefits include fewer spurious conflicts, better detection of true structural conflicts, reduced broken builds and regressions caused by missed conflicts, and easier maintainability because improvements in the core engine propagate across all supported languages. Future work highlighted in the paper includes extending language coverage, improving handling of renamings and complex refactorings, and exploring further hybrid strategies that combine structured, semistructured, and unstructured merge (Duarte et al., 25 Jul 2025).