`dolt conflicts resolve <table> --combine-ours` or `--combine-theirs`

[alecstein]

The dolt API matches the git API almost exactly but I think there's a place where dolt could profitably diverge from it.

It often happens that when two users submit data they're working with partially disjoint sets of information. (At least, this happens a lot during Dolthub bounties.) Suppose we have a table called birthday_info with names, dates, favorite cakes and favorite colors. Two users, Person A and Person B, are trying to enter information about the same person, Ally. A might get Sally's birthday and favorite cake, whereas Person B might find Sally's favorite color.

A commits their row, followed by person B, resulting in the following table with merge conflicts:

| name (pk) | birthday    | favorite_cake | favorite_color |
|-----------|-------------|---------------|----------------|
| Sally     | 1990-04-05  | chocolate     | null           | <- submitted by A (first)
| Sally     | null        | null          | blue           | <- submitted by B (second -- creates conflict)

Because name is a primary key this results in a merge conflict. But this is what you want with git -- it's not really what you want with dolt, the primary use case of which is collaborative table editing. The problem with the current API is that dolt conflicts resolve birthday_info --ours (or --theirs) just picks arbitrarily one part of the data.

But dolt is table-based so you can do better than git. To resolve this you could create a flag which takes either the existing rows and fills those nulls with --theirs, or do the opposite, and fill the new rows' nulls using the non-null values in the existing rows.

So in the case of disjoint data this might look like:

| name (pk) | birthday    | favorite_cake | favorite_color |
|-----------|-------------|---------------|----------------|
| Sally     | 1990-04-05  | chocolate     | blue           | <- submitted by both A, B

If the data isn't perfectly disjoint, you'd need to pick a cell from either A or B. Consider this setup:

| name (pk) | birthday    | favorite_cake | favorite_color |
|-----------|-------------|---------------|----------------|
| Sally     | 1990-04-05  | chocolate     | null           | <- submitted by A (first)
| Sally     | null        | vanilla       | blue           | <- submitted by B (second -- creates conflict)

Then dolt conflicts resolve birthday_info --combine-ours gives

| name (pk) | birthday    | favorite_cake | favorite_color |
|-----------|-------------|---------------|----------------|
| Sally     | 1990-04-05  | chocolate     | blue           | <- submitted by both A, B

and dolt conflicts resolve birthday_info --combine-theirs gives

| name (pk) | birthday    | favorite_cake | favorite_color |
|-----------|-------------|---------------|----------------|
| Sally     | 1990-04-05  | vanilla       | blue           | <- submitted by both A, B

[timsehn]

Note this only happens if both branches are adding he same primary key. If they had both modified that row, it would merge fine.

Is defining the same primary key but different columns in the key a conflict?

[druvv]

It looks like we don't cell-wise merge rows if the same key is added on both side of the merge. I think it would be correct to cell-wise merge them.

[timsehn]

I think I agree.