git_log(NULL) silently returns empty results instead of raising an error

[teaguesterling]

Description

git_log(NULL) silently returns 0 rows, while git_branches(NULL) returns results (apparently falling back to cwd). This inconsistency makes it difficult to diagnose when a NULL path is passed unintentionally.

Reproduction

LOAD duck_tails;

-- Returns 0 rows, no error
SELECT * FROM git_log(NULL) LIMIT 3;

-- Returns rows (falls back to cwd)
SELECT * FROM git_branches(NULL) LIMIT 3;

-- Works as expected
SELECT * FROM git_log('.') LIMIT 3;

Expected behavior

Either:

• git_log(NULL) should raise an error (preferred — makes bugs visible), or
• git_log(NULL) should fall back to cwd, matching git_branches(NULL) behavior

The current silent-empty-result behavior is the worst of both worlds — it doesn't fail visibly, and it doesn't produce useful output.

Context

Discovered while building MCP tool wrappers for duck_tails in source-sextant. A session variable providing the repo path was unexpectedly NULL in the MCP execution context. git_branches appeared to work while git_log returned nothing, making the root cause hard to isolate.