🤖 AI Summary
This work addresses the lack of rigorous correctness criteria in existing three-way merge tools, which often produce syntactically invalid outputs or lose edits. It formally defines merge correctness for software artifacts based on two syntactic properties—parsability and generality—and leverages the categorical notion of pushout to precisely characterize merge semantics. Guided by this formalism, the authors develop a structured merge tool that achieves zero syntactic errors across 43,774 Java file merge scenarios, substantially outperforming mainstream tools such as Git. Experimental comparisons against developer-performed manual merges and cases involving refactorings further validate the approach’s effectiveness and delineate its practical applicability boundaries.
📝 Abstract
Three-way merge tools play crucial roles in modern software development, where a developer forks a branch to make local modifications and requests it to be merged into the main branch via a "pull request." Despite its importance, the task has traditionally been defined in an intuitive manner, and the results of merge tools are often accepted without scrutiny. In this paper, we present a new structural merge tool in comparison with existing tools based on the syntactic criteria we propose for evaluating the merge results. We require the merge result to be both parsable and universal. Being parsable means that the result is syntactically valid according to the grammar of the programming language. Being universal means that the result incorporates all and only the edit operations occurring in each branch while ensuring that edits common to both branches are applied only once. This requirement can be precisely defined using the notion of pushouts in category theory. In a large-scale experiment involving 43,774 file merge scenarios from 76 open-source Java projects, we found a number of incorrect results reported by existing tools such as the Git companion merge tool, whereas our tool reports none. We further compared d3j's results with 2,582 developer-resolved merges and with 2,459 merge scenarios involving 21 refactoring types. These experiments revealed both the strengths and current limitations of structural merge, and underscore the importance of clear correctness criteria. We expect that the proposed criterion will provide a foundation for developing more reliable and principled merge tools.