Much like platforms such as GitLab do with merge requests, I would like to inform the user if the changes they are making are 'going to' conflict with another branch or revision. I can fetch conflicts after doing a merge, but to avoid leaving the user's branch in an unmerged state (because they don't want to actually merge yet), I first fork a temporary branch from the user's branch, perform the merge there, get the conflicts, and then discard that branch.

This works well, but I've noticed that DOLT_BRANCH, with or without --copy, does not take over working changes (WORKING) made to the source branch. This makes this approach unfeasible to simulate conflicts with the user's currently uncommitted changes. I kind of expected the current behaviour for the MySQL server, but also hoped there was some way to do this anyway (at least for the MySQL server), perhaps through an additional flag. (I realise a merge might not be possible with uncommitted changes but in that case I would try to compile them into a temporary commit.)

There are some workarounds, but I'm not sure they are optimal:

• I can do the merge on the original branch (so without temporary branch), and then abort it using DOLT_MERGE. This has a few caveats:
  • Reentrancy. I'm doing this in an API, and there may be multiple calls to simulate conflicts with multiple other branches for a single source branch. I'd need to lock that branch to ensure one merge conflict simulation finishes before the next. With temporary branches this matters little.
  • The documentation says try to reconstruct the pre-merge state., I'm not sure I like the word try here - it seems to imply it can't always work 100%, and I really don't want to touch the user's changes unless they explicitly want to merge.
• Try to copy over the workspace changes myself, which is a bit tedious.
• Try to use stashes. Could work, but will also affect the actual branch and require restoring immediately, which can also result in reentrancy issues (but sounds better than doing the merge on the actual branch). The documentation also doesn't mention a way to 'apply' without dropping like Git supports, which I'd need to do to restore it on the original branch and on the temporary branch afterwards.
• Make a commit on the actual branch, fork from that commit, then try to rewrite history to get that commit off the actual branch (or worst case drop/recreate actual branch from old commit). This has similar reentrancy problems because the original branch is affected.

This was tested with Dolt 2.1.6.

(This might be related to #2723 but I'm not sure my use case is the same.)

EDIT: Another workaround is using DOLT_PATCH('HEAD', "WORKING') on the branch to get all statements applied, then fork the branch, and then reapply those one by one in order, to replicate the working state on the new branch.