Detecting Build Conflicts in Software Merge for Java Programs via Static Analysis

During software merge, the edits from different branches can textually overlap (i.e., textual conflicts) or cause build and test errors (i.e., build and test conflicts), jeopardizing programmer productivity and software quality. Existing tools primarily focus on textual conflicts; few tools detect higher-order conflicts (i.e., build and test conflicts). However, existing detectors of build conflicts are quite limited. Due to their heavy usage of automatic build, the build-based detectors (e.g., Crystal) can only report build errors instead of pinpointing the root causes; developers have to manually locate conflicting edits. Furthermore, these detectors only help when the branches-to-merge have no textual conflict. We present a novel approach Bucond (“build conflict detector”) to detect conflicts via static analysis, instead of using automatic build. Given the three program versions in a merging scenario: base 𝑏, left 𝑙 , and right 𝑟 , Bucond first models each version as a graph, and compares graphs to extract entity-related edits (e.g., rename a class) in 𝑙 and 𝑟 branches. Our insight is that build conflicts occur when certain edits are co-applied to related entities between branches. Bucond realizes this insight via pattern-based reasoning, to identify any cross-branch edit combination that can trigger build conflicts (e.g., one branch adds a reference to field F while the other branch removes F). We conducted a systematic exploration to devise 57 conflicting-edit patterns, covering 97% of total build conflicts in our experiments. We evaluated Bucond with three datasets and Bucond worked effectively on all datasets. It complements existing build-based conflict detectors, as it (1) detects conflicts with 100% precision and 88%–100% recall, (2) pinpoints the conflicting edits, and (3) works well when those detectors are inapplicable.