A customer we talked to overrides Dolt's merge logic because they want to implement custom rules on merges that Dolt does not give visibility into. For instance, for their use case, a data change and a schema change on the same table is "a conflict" and they prompt their users to resolve. The example they gave was a row addition and an added column where the user must fill in the new column for their new row in order to complete the merge.

To resolve this use case, they now make the schemas match in one commit and then do a data merge, leaving two commits in their log, which is not ideal.

This brought up a number of interesting feature requests, but for this issue I will focus on the "custom merge".

1. The user would love to be able to open an "empty merge" and pick the working set (left, right, or "dolt merged") to be the edit base. Then they would like to make edits and commit the merge. --squash is the "dolt merge" version but this feature request is to choose the appropriate merge base.
2. They would like appropriate status functions like dolt_is_merging() to manage the state of their merge.
3. When the working set is ready, they would like to then make a commit and have this commit show up in their logs. This is already what happens with --squash