test: assert the repo escape hatch works at depth, not that it fails

[mizchi]

Fixes #196.

This is the spec call I flagged in #199 rather than guessing at. Having dug into it, the test's expectation is wrong and the behaviour is right — so this changes the test. Reasoning below in case you read it the other way.

The assertion

test_expect_success 'repo status from deep nested path fails as plain repo command' '
	if $BIT -C nested/a/b/c repo status > nested-repo-nested.out 2>&1; then
	  false
	else
	  true
	fi &&
	grep "Not a git repository" nested-repo-nested.out
'

Why the behaviour is right

bit repo is documented as a pass-through, not a path pin. print_repo_usage says it exists to "bypass workspace implicit command translation and run regular bit commands", and that is how it is built: handle_repo hands the command straight to dispatch_command with no notion of pinning to the given directory. (run_workspace_repo_command does take a cwd, but it is the callback handle_workspace uses to run a command against each workspace node — nothing to do with bit repo.)

A regular command walks up, exactly as git does. Real git in the same fixture agrees:

$ bit -C nested/a/b/c repo status
On branch master
nothing to commit, working tree clean

$ (cd nested/a/b/c && git status)
On branch master
nothing to commit, working tree clean

Making the escape hatch fail below the repository root would be a git-compatibility regression. Someone inside a workspace who cds into a subdirectory and reaches for bit repo status to get plain behaviour would get an error instead.

The expected string is not reachable. "Not a git repository" is raised only by push and submodule when validating a remote or submodule URL — never by status. Nothing in the dispatch path could have produced it, so this case cannot have passed since it was added in #139. Nothing under t/ runs in CI, which is how it stayed that way.

The change

The case now asserts the property the file is actually about — the escape hatch bypasses translation at any depth — mirroring the preceding case at the workspace root:

test_expect_success 'repo status from deep nested path also bypasses workspace translation' '
	$BIT -C nested/a/b/c repo status > nested-repo-nested.out 2>&1 &&
	grep "On branch" nested-repo-nested.out &&
	! grep "workspace root:" nested-repo-nested.out
'

If you intended bit repo to pin to the exact directory, say so and I will implement that instead — it would mean a change in handle_repo plus a doc update, and I would want to check it against the git-compat suite first.

Verification

t9007 goes 5/6 → 6/6, and with it the whole t9 range is green:

t900   Total 11   Passed 11   Failed 0
t901   Total  8   Passed  8   Failed 0
t902   Total  2   Passed  2   Failed 0

Measured with GIT_CONFIG_* unset, for the reason given in #199.

This unblocks wiring t/ into CI

Three PRs in a row now — #192, #199 and this one — have merged with CI validating essentially nothing, because no job invokes the test-subdir task and select skips everything for a t/-only diff. That is also why t9014, t90010 and this assertion sat broken without anyone noticing.

The blocker for fixing that was the red tests, and they are now all green. Happy to open a follow-up that adds a CI job for the t/ suite if you want it — worth deciding whether it covers the whole tree or just t9, since I have not audited t0xxx here.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VDVUJHu38YtVAr6sKZtRDB

---

Generated by Claude Code