Skip to content

bug: DOLT_CHECKOUT -b ignores --no-overwrite-ignore when called directly via SQL #10802

Description

@codeaucafe

Bug

CALL DOLT_CHECKOUT('-b', 'newbranch', '--no-overwrite-ignore', 'HEAD~1') succeeds even when an ignored table has different content at HEAD~1. The flag is parsed but never checked.

The CLI equivalent (dolt checkout -b newbranch --no-overwrite-ignore HEAD~1) correctly blocks the checkout.

Reproduction

CREATE TABLE ignored_tbl (pk int PRIMARY KEY, val int);
INSERT INTO ignored_tbl VALUES (1, 100);
INSERT INTO dolt_ignore VALUES ('ignored_tbl', true);
CALL dolt_add('-A', '--force');
CALL dolt_commit('-m', 'add ignored table on main', '--force');

INSERT INTO ignored_tbl VALUES (2, 200);
CALL dolt_add('-A', '--force');
CALL dolt_commit('-m', 'modify ignored table', '--force');

-- Expected: error  |  Actual: succeeds
CALL dolt_checkout('-b', 'newbranch', '--no-overwrite-ignore', 'HEAD~1');

Root Cause

In checkoutNewBranch (go/libraries/doltcore/sqle/dprocedures/dolt_checkout.go), the isMove=false path calls SwitchWorkingSet without calling CheckOverwrittenIgnoredTables. The isMove=true path correctly runs the check via doGlobalCheckout -> MoveWorkingSetToBranch.

checkoutExistingBranch in the same file handles both paths correctly.

Fix

Inside checkoutNewBranch, above err = sess.SwitchWorkingSet(ctx, dbName, wsRef) apply the same check as in checkoutExistingBranch:

if !overwriteIgnore {
			if currentRoots, hasRoots := dSess.GetRoots(ctx, dbName); hasRoots {
				branchHead, err := actions.BranchHeadRoot(ctx, ddb, branchName)
				if err != nil {
					return err
				}
				if err := actions.CheckOverwrittenIgnoredTables(ctx, currentRoots, branchHead, overwriteIgnore); err != nil {
					return err
				}
			}
		}

Context

I introduced the --overwrite-ignore / --no-overwrite-ignore flags in PR #10549. While walking a friend through and explaining the PR, I noticed that checkoutNewBranch doesn't check the flag in its isMove=false path, even though checkoutExistingBranch does. Tested it and confirmed the bug is real.

I will push up a PR for this.

Refs: #10488

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions