Allow resolving schema conflicts when there can't possibly be data conflicts because one side of the merge was deleted.

Author: nicktobey

go/libraries/doltcore/sqle/dprocedures/dolt_conflicts_resolve.go

@@ -352,26 +352,28 @@ func ResolveSchemaConflicts(ctx *sql.Context, ddb *doltdb.DoltDB, ws *doltdb.Wor
 		return ws, nil // no schema conflicts
 	}
 
-	// TODO: There's an issue with using `dolt conflicts resolve` for schema conflicts, since having
-	//
-	//	schema conflicts reported means that we haven't yet merged the table data. In some case,
-	//	such as when there have ONLY been schema changes and no data changes that need to be
-	//	merged, it is safe to use `dolt conflicts resolve`, but there are many other cases where the
-	//	data changes would not be merged and could surprise customers. So, we are being cautious to
-	//	prevent auto-resolution of schema changes with `dolt conflicts resolve` until we have a fix
-	//	for resolving schema changes AND merging data (including dealing with any data conflicts).
-	//	For more details, see: https://github.com/dolthub/dolt/issues/6616
-	if ws.MergeState().HasSchemaConflicts() {
-		return nil, fmt.Errorf("Unable to automatically resolve schema conflicts since data changes may " +
-			"not have been fully merged yet. " +
-			"To continue, abort this merge (dolt merge --abort) then apply ALTER TABLE statements to one " +
-			"side of this merge to get the two schemas in sync with the desired schema, then rerun the merge. " +
-			"To track resolution of this limitation, follow https://github.com/dolthub/dolt/issues/6616")
-	}
-
 	tblSet := doltdb.NewTableNameSet(tblNames)
 	updates := make(map[doltdb.TableName]*doltdb.Table)
 	err := ws.MergeState().IterSchemaConflicts(ctx, ddb, func(table doltdb.TableName, conflict doltdb.SchemaConflict) error {
+		// If one side dropped the table, we don't need to worry about correctly merging data. Otherwise, be cautious
+		// and prevent the merge.
+		if conflict.ToSch != nil && conflict.FromSch != nil {
+			// TODO: There's an issue with using `dolt conflicts resolve` for schema conflicts, since having
+			//	schema conflicts reported means that we haven't yet merged the table data. In some cases,
+			//	such as when one side of the branch drops the table, or when there have ONLY been schema changes
+			//	and no data changes that need to be merged, it is safe to use `dolt conflicts resolve`, but there are
+			//	many other cases where the data changes would not be merged and could surprise customers. So, we are
+			//	being cautious to prevent auto-resolution of schema changes with `dolt conflicts resolve` until we have
+			//	a fix for resolving schema changes AND merging data (including dealing with any data conflicts).
+			//	For more details, see: https://github.com/dolthub/dolt/issues/6616
+			if ws.MergeState().HasSchemaConflicts() {
+				return fmt.Errorf("Unable to automatically resolve schema conflicts since data changes may " +
+					"not have been fully merged yet. " +
+					"To continue, abort this merge (dolt merge --abort) then apply ALTER TABLE statements to one " +
+					"side of this merge to get the two schemas in sync with the desired schema, then rerun the merge. " +
+					"To track resolution of this limitation, follow https://github.com/dolthub/dolt/issues/6616")
+			}
+		}
 		if !tblSet.Contains(table) {
 			return nil
 		}