Dolt is Git for data. One of the most powerful features of Git is the ability to view and resolve merge conflicts when two developers make code changes on different branches to the same line. In Dolt, conflicts can also be triggered but follow more complicated rules. Data conflicts arise when two editors modify the same cell (ie. row, column pair). Schema conflicts can also occur but follow different rules.

Previously, resolving Dolt conflicts required using SQL or the CLI to inspect conflict tables and run resolution procedures. We recently added the ability to preview merge conflicts in our web products. Now we're taking the next step: you can resolve merge conflicts from the pull request interface on the web.

How does resolving conflicts work?

When two branches modify the same data, Dolt creates merge conflicts that need to be resolved before the merge can complete. Here's how the conflict resolution process works.

Starting the merge

First, you need to start the merge with autocommit disabled. Autocommit must be off because resolving conflicts requires multiple steps - viewing the conflicts, making resolution decisions, and then committing the final result. With autocommit enabled, Dolt would attempt to automatically commit the merge, but since conflicts exist, the merge would fail immediately rather than allowing you to resolve them.

When you start a merge with conflicts, Dolt creates a working state where you can inspect and resolve the conflicts before finalizing the merge with a commit.

Viewing conflicts

Once a merge with conflicts is initiated, Dolt exposes the conflicts through system tables:

• dolt_conflicts: A summary table showing which tables have conflicts and how many
• dolt_conflicts_$tablename: Individual tables for each table with conflicts, containing the conflicting rows with columns showing the "base", "ours", and "theirs" versions of the data

These system tables allow you to see exactly which rows are in conflict and what the competing values are for each conflicted cell.

Two ways to resolve conflicts

There are two approaches to resolving data conflicts in Dolt and Doltgres:

1. Choosing "ours" or "theirs" using the dolt_conflicts_resolve procedure (supported from the web)

This is the simpler approach where you choose to accept either all changes from the base branch ("ours") or all changes from the merging branch ("theirs") for each conflicted table. You can call the dolt_conflicts_resolve procedure with parameters specifying your choice of "ours" or "theirs" and the table name(s). This approach is now supported in our web interface, allowing you to resolve conflicts without needing to connect to the SQL shell.

2. Manually resolving conflicts by modifying the base table and deleting conflict rows (not yet supported on the web)

For more granular control, you can manually resolve conflicts by directly modifying rows in the base table to your desired final state, then deleting the corresponding conflict rows from the dolt_conflicts_$tablename tables using their primary keys. This approach gives you more control over the resolution - you can combine values from "ours" and "theirs", or create entirely new values. This method requires SQL commands and is currently only available through SQL. We hope to eventually support this behavior from the web.

Schema conflicts

Schema conflicts occur when both branches modify the structure of a table (adding/removing columns, changing data types, etc.). These conflicts are separate from data conflicts and follow more complex resolution rules. Schema conflict resolution is not yet supported from the web interface due to their complexity and is better handled from the SQL shell where you have full control over the schema merge process.

How to use the feature

Let's walk through an example using the employees database from our previous conflict preview blog. In this scenario, two colleagues using the Dolt Workbench desktop app need to:

1. Apply a rounding strategy to the salary column in the salaries table
2. Fix to_date values for active titles in the titles table

This creates the perfect scenario for merge conflicts when two colleagues modify the same data.

Setting up the conflict scenario

Colleague One's approach:

• Rounds salaries up to the nearest thousand
• Sets active title to_date values from 9999-01-01 to NULL for cleaner data representation

Colleague Two's approach:

• Rounds salaries down to the nearest thousand
• Updates active title to_date values to 3000-01-01 for future-proofing

The conflict emerges

Colleague One merges their changes first:

Now when Colleague Two tries to merge, they encounter conflicts since both colleagues modified the same cells:

Resolving conflicts from the web

The old way: Colleague Two would need to connect to the SQL server, run merge commands, and manually resolve conflicts using procedures or by editing conflict tables directly. (See the manual steps here.)

The new way: Colleague Two can resolve everything from the web interface!

First, they inspect the conflicting data. For the salaries table, they decide their rounding-down approach is better:

For the titles table, they prefer Colleague One's cleaner NULL approach over their 3000-01-01 values:

Using the "Resolve conflicts and merge" button, Colleague Two selects their resolution strategy:

• theirs for salaries (keep their own rounding-down changes)
• ours for titles (keep Colleague One's NULL values)

The final result

After resolving conflicts and completing the merge, the database reflects the chosen resolution strategy:

• salaries table contains the rounded-down values (Colleague Two's approach)
• titles table retains the NULL to_date values (Colleague One's approach)

Both colleagues can now continue their work with a cleanly merged dataset that combines the best of both approaches.

What's next for conflicts on the web

Conflict resolution on DoltHub/DoltLab

Web-based conflict resolution is currently available on Hosted Dolt and the Dolt Workbench. Due to architectural differences with DoltHub/DoltLab, implementing this feature there requires additional work and will take more time.

More granular conflict resolution on the web

Currently, you choose a resolution strategy per table ("ours" or "theirs"). We're planning a more sophisticated UI that lets you resolve conflicts row-by-row or cell-by-cell, similar to GitHub's conflict resolution interface.

Schema conflict support from the web

Schema conflicts involve structural table changes and are significantly more complex than data conflicts. For now, these require the SQL shell, but we're exploring ways to make schema conflicts more manageable from the web.

Conclusion

Web-based conflict resolution removes a barrier to collaborative data work in Dolt. Instead of requiring SQL or CLI expertise, team members can now resolve most conflicts directly from familiar pull request interfaces.

Try it out on Hosted Dolt or the Dolt Workbench, and let us know what you think on Discord. We always appreciate your feedback!