gitstatus: staged adds and deletes may be renames, deferring

Error message

gitstatus: staged adds and deletes may be renames, deferring to git

What it means

diffStaging pairs staged adds and deletes to detect renames cheaply. If both unpaired adds and unpaired deletes remain, some may actually be renames (content moves), which the heuristic cannot confirm. Since rename detection needs git's rename scoring, the implementation deliberately refuses to guess and reports this sentinel so the caller defers to git's status output.

Source

Thrown at src/gitstatus/staging.go:134

	for _, h := range added {
		if remaining[h] <= 0 {
			unpairedAdds++
			continue
		}

		remaining[h]--
		counts.Added--
		counts.Deleted--
		counts.Modified++
	}

	unpairedDeletes := 0
	for _, n := range remaining {
		unpairedDeletes += n
	}

	if unpairedAdds > 0 && unpairedDeletes > 0 {
		return errors.New("gitstatus: staged adds and deletes may be renames, deferring to git")
	}

	return nil
}

View on GitHub (pinned to 0976794618)

Solutions

Treat this error as a signal to fall back to 'git status --porcelain' output for authoritative staged status
If you control the flow, cache the git status result and only use the fast path when no mixed add/delete staging exists
Check whether rename detection can be enabled in the comparison (pair by content similarity) before bailing

Example fix

// before
err := diffStaging(index, worktree, &status)
if err != nil { return err }
// after
err := diffStaging(index, worktree, &status)
if err != nil {
    // staged adds+deletes may be renames; defer to git
    return parseGitStatus(env, &status)
}

Defensive patterns

Strategy: fallback

Try / catch

if err := diffStaging(index, worktree, &status); err != nil {
    if strings.Contains(err.Error(), "may be renames") {
        return parseGitStatusPorcelain(env, &status)
    }
    return err
}

Prevention

Never guess rename classification without content comparison
Cache git porcelain output so the fallback is cheap
Log when the fast path defers to git to detect perf regressions

When it happens

Trigger: Running diffStaging when the index contains both newly added files and deletions that don't pair up exactly by hash - e.g. git mv, or staging a file edit under one path while deleting another.

Common situations: User runs 'git mv a b' then edits b; prompt status shows staged adds+deletes and the fast path can't classify them, so status accuracy would be wrong without rename detection.

Related errors

AI-assisted analysis of JanDeDobbeleer/oh-my-posh@0976794618 (2026-08-31). Data as JSON: /api/errors/f4a3dcc864ef7b0c. Report an issue: GitHub.