getBranchMergedStatus: is `git merge-base --is-ancestor` exit code 1 intentionally logged as `[error]`?

[nikolay-1986]

Observation

When working with a worktree branch (or any branch that has commits ahead of main), the GitLens Output channel shows repeated [error] entries:

[error]   [GIT] [.../Test-worktree] git merge-base --is-ancestor Test-worktree main • Command failed with exit code 1 [52ms]
[error]   [GIT] [.../Test-worktree] git merge-base --is-ancestor Test-worktree origin/main • Command failed with exit code 1 [65ms]

These appear on every getBranchMergedStatus computation — e.g., when switching to a worktree, refreshing the sidebar, or opening branch panels.

Context

git merge-base --is-ancestor is a boolean git command:

Exit code	Meaning
0	Branch IS an ancestor (merged)
1	Branch is NOT an ancestor — valid "false" answer
128+	Actual git error

In getBranchMergedStatusCore (src/env/node/git/sub-providers/branches.ts:784), the call currently uses errors: 'throw':

// branches.ts — getBranchMergedStatusCore
await this.git.exec(
    { cwd: repoPath, cancellation: cancellation, errors: 'throw' },
    'merge-base', '--is-ancestor',
    branch.name, into.name,
);
return { merged: true, confidence: 'highest' };
// catch silently discards non-cancellation errors

With errors: 'throw', both exit code 1 ("not ancestor") and exit code 128+ (real git errors) are thrown as GitError. The catch block re-throws only CancellationError and discards the rest — but the [error] line is already written to the Output channel before the discard.

For comparison, CommitsGitSubProvider.isAncestorOf (src/env/node/git/sub-providers/commits.ts:1160) calls the same command with exitCodeOnly: true and explicitly interprets exit code 0 as true:

// commits.ts — isAncestorOf
const result = await this.git.exec(
    { cwd: repoPath, cancellation: cancellation, exitCodeOnly: true },
    'merge-base', '--is-ancestor',
    rev1, rev2,
);
return result.exitCode === 0;

Question

Is the errors: 'throw' pattern in getBranchMergedStatusCore intentional? If so, what is the reasoning — perhaps to treat real git errors (exit 128+) the same as "not ancestor" in this specific context?

If unintentional, the fix would be to align with the pattern in commits.ts using exitCodeOnly: true, which would eliminate the false [error] noise from the Output channel.