Understanding Semantic Change Interactions in Merge Conflicts

Abstract

Merge conflicts occur when concurrent changes to a software project cannot be automatically reconciled by a version control system such as Git. A three-way merge provides several concrete artifacts for studying such conflicts: the common ancestor (base), the two conflicting variants (ours and theirs), and the final resolution.

The textual overlap reported by Git does not necessarily imply a semantic conflict. Two branches may modify the same lines while implementing conceptually independent changes, or they may make changes that directly compete, depend on each other, or alter the same behavior in incompatible ways.

This project investigates merge conflicts at this semantic level. It aims to characterize (1) the semantic changes represented by ours and theirs, (2) the relationship between these concurrent changes, and (3) how the final resolution consolidates them. The result should be an empirically grounded taxonomy and an annotated dataset of real-world merge conflicts.

Motivation

A merge conflict is first detected because two branches contain textual edits that Git cannot reconcile automatically. However, the underlying development changes can relate to each other in very different ways.

For example, one branch may migrate a component to a new API while another branch independently extends functionality using the previous API. In this case, the changes are semantically related because one depends on an interface that the other changes.

In another case, one branch may rename a local variable while another adds logging nearby. The edits may overlap textually and therefore trigger a merge conflict, even though the two changes are semantically independent and can both be preserved.

This suggests that a conflict should not be described only by its textual overlap or by a single “conflict cause”. Instead, it can be studied through the following dimensions:

• Change semantics in ours: What development change does ours make relative to base?
• Change semantics in theirs: What development change does theirs make relative to base?
• Change interaction: How do the two semantic changes relate to each other?
• Consolidation strategy: How does the final resolution reconcile the two changes?

The intended classification should therefore abstract from low-level edit operations such as “line added”, “method renamed”, or “block moved”. The focus is on the semantic meaning of the changes and on the role of the final resolution.

A systematic characterization of these dimensions could improve our understanding of real-world merge conflicts and provide a foundation for future techniques for conflict classification, prediction, and resolution support.

Goal

The goal of this project is to develop an empirically grounded taxonomy for semantic changes, change interactions, and consolidation strategies in merge conflicts.

The following research questions provide an initial focus:

• RQ1: What recurring semantic types of changes are involved in merge conflicts?
• RQ2: What recurring semantic relationships occur between the concurrent changes in ours and theirs?
• RQ3: How are different combinations of changes and interactions consolidated in the final resolution?

The categories are not intended to be fixed beforehand. They should emerge from the empirical analysis and may be refined as additional conflicts are investigated.

Semantic change types

Possible semantic change types that can serve as initial hypotheses include:

• feature addition or extension,
• corrective change or bug fix,
• behavior-preserving refactoring,
• behavior-changing modification,
• API or interface evolution,
• dependency or configuration evolution,
• test evolution,
• restructuring or movement of functionality,
• code removal or deprecation.

These categories describe the meaning of a change in ours or theirs relative to base. They are not meant to capture simple textual edit patterns.

Change interactions

Possible relationships between the two concurrent changes include:

• semantically independent / syntactic overlap — the edits overlap textually, but both semantic changes can coexist without conceptual conflict,
• complementary — the changes address different aspects that naturally belong together,
• dependency / adaptation — one change depends on an element that the other changes, such as a feature developed against an old API,
• competing alternatives — both branches attempt to address the same concern in different ways,
• overlapping semantic modification — both branches modify the same behavior or concept, but are not simply equivalent alternatives,
• redundant / equivalent — both branches implement essentially the same semantic change in different ways,
• incompatible — both intended changes cannot be preserved together without an additional design decision.

These are initial working concepts. One important outcome of the study may be to determine how often textual merge conflicts are actually semantically independent changes with only syntactic overlap.

Consolidation strategies

The final resolution can then be characterized by how it consolidates the two concurrent changes. Possible starting categories include:

• select one change — retain essentially one side and discard the other,
• preserve both — combine complementary changes without substantial semantic adaptation,
• adapt / migrate — modify one change so that it becomes compatible with the other,
• synthesize — create a new solution that incorporates the intentions of both sides,
• discard / replace — replace the competing alternatives with a different solution,
• partial / incomplete consolidation — leave the conflict only partially resolved, duplicate code, or retain unresolved conflict artifacts.

These consolidation categories should also be treated as hypotheses rather than a prescribed taxonomy.

Example

A conflict can be represented as:

A different conflict might look like:

Possible analysis matrix

One possible result is a matrix of the semantic changes observed in both branches:

Each populated cell can then be analyzed with respect to the observed interaction types and consolidation strategies. For example, conflicts combining API evolution and feature development might predominantly require adaptation or migration, whereas conflicts involving semantically independent changes might mostly be resolved by preserving both.

The rows, columns, interaction categories, and consolidation categories are all starting points. Their final form is an outcome of the project.

Project Plan

The following plan provides a starting point and can be adapted based on observations made during the project.

1. Sampling and annotation support

An existing dataset of historical merge conflicts and infrastructure for generating HTML reports of individual conflicts are available as starting material. The reports present base, ours, theirs, surrounding source-code context, and the final resolution in a form suitable for manual inspection.

As an engineering component of the project, this infrastructure should be extended with a lightweight tool for sampling, tracking, and documenting the qualitative analysis.

The tool could support:

• selecting conflicts from the available dataset,
• opening or embedding the corresponding conflict report,
• recording the semantic change in ours,
• recording the semantic change in theirs,
• recording the interaction between both changes,
• recording the consolidation strategy of the final resolution,
• assigning multiple labels where necessary,
• adding free-text observations and classification rationale,
• marking cases as ambiguous, unsuitable, or requiring additional context,
• tracking reviewed, pending, and excluded conflicts,
• revisiting earlier classifications when the taxonomy changes,
• recording substantial taxonomy changes and their rationale,
• exporting annotations to a structured representation such as CSV or JSON.

The goal is not to build a general-purpose annotation platform. The tool should primarily make the empirical study systematic, traceable, reproducible, and easy to revise.

2. Exploratory sample

An initial sample of approximately 20–30 conflicts can be studied in detail using open coding, i.e., by inspecting the cases without a fixed taxonomy and assigning descriptive labels to recurring semantic patterns as they emerge from the data.

For each case, the analysis should examine:

• what semantic change ours makes relative to base,
• what semantic change theirs makes relative to base,
• how the two changes relate to each other,
• whether the conflict is semantic or mainly a syntactic overlap,
• how the final resolution consolidates both changes,
• which contextual information is necessary to understand the conflict.

Recurring observations can be grouped into preliminary categories. Each category should be documented with a concise name, a definition, representative examples, and relevant boundary cases.

3. Taxonomy development

The preliminary taxonomies can then be applied to approximately 50–70 additional conflicts.

During this phase, the taxonomy itself is refined iteratively as new conflicts are analyzed. Candidate categories can be adjusted when the observed cases suggest that the current classification does not capture the underlying semantic distinctions well.

Substantial changes to the taxonomy and their rationale should be documented so that its evolution remains traceable and earlier annotations can be revisited consistently.

This phase can also investigate questions such as:

• Can a single branch contain more than one relevant semantic change?
• Can a conflict involve several interaction types?
• Can a resolution use several consolidation strategies?
• At what level of abstraction are semantic change categories most useful?
• Which distinctions are merely syntactic and should not form semantic categories?
• How often do syntactic conflicts occur between semantically independent changes?
• How often is information outside the immediate conflicting chunk required?

4. Consolidation sample

Once the classification scheme has become reasonably stable, another 30–50 previously unseen conflicts can be analyzed using the consolidated taxonomy.

This phase provides an indication of whether the categories continue to describe cases that were not involved in their development.

A reasonable initial sampling plan is:

These numbers are planning values rather than strict requirements. Some conflicts may be understood quickly, while others may require substantial investigation of surrounding code or repository history.

To keep the analysis focused, the initial study can concentrate on one programming language. Extending the analysis to additional languages can be considered if time permits.

Analysis and Deliverables

The resulting annotation dataset could contain information such as:

The final analysis can investigate:

• which semantic change types occur most frequently,
• which combinations of changes commonly lead to textual merge conflicts,
• how often conflicting edits are semantically independent,
• which interaction types occur most frequently,
• which consolidation strategies are used for different combinations of changes,
• whether certain interactions tend to require more complex consolidation,
• which categories are difficult to distinguish,
• how frequently multiple labels are required,
• and when additional repository context is necessary.

The quantitative matrices should be complemented by representative cases and a qualitative discussion of clear, unusual, and ambiguous examples.

The expected project outcomes are:

• an empirically grounded taxonomy of semantic change types involved in merge conflicts,
• an empirically grounded taxonomy of semantic interactions between concurrent changes,
• an empirically grounded taxonomy of consolidation strategies used in final resolutions,
• an annotated dataset of approximately 100–150 real-world merge conflicts,
• a lightweight tool supporting conflict sampling, inspection, annotation, and taxonomy refinement,
• an empirical analysis relating semantic change combinations, interactions, and consolidation strategies,
• representative examples illustrating the identified categories,
• a discussion of syntactic versus semantic conflicts, ambiguous cases, required contextual information, and limitations of the resulting taxonomy,
• a final seminar presentation summarizing the methodology and findings.

Requirements

Basic knowledge of Git and software development is expected. Experience with at least one programming language such as Java or Python and basic scripting skills are useful. An interest in empirical software engineering and in systematically understanding source-code changes is important.

Pointers

The following material will be provided as a starting point for the project:

• an existing dataset of historical merge conflicts,
• an existing HTML report generator for inspecting individual conflicts,
• example conflict cases and exploratory classifications that can be used to bootstrap the analysis.
• Towards Semi-Automated Merge Conflict Resolution: Is It Easier Than We Expected?

Additional literature on merge conflicts, software evolution, and qualitative taxonomy construction can be identified during the project.

Contact

Manuel Ohrndorf