pub fn repo_branch_names(repo: &Path) -> Option<RepoBranches>Expand description
Every branch name the repo rooted exactly at repo knows, plus how
many branch refs it actually holds. None when repo is not itself
a work-tree root or git could not be asked.
One listing, then exact string membership. That is the difference
between this and asking branch_ref_exists per branch: a
for-each-ref pattern matches path prefixes, so a stored fix
matches fix/anything, an empty name matches every head, and a name
carrying [, a leading - or a space matches nothing and exits 0 -
indistinguishable from a branch that is genuinely gone. A caller that
deletes on absence cannot tell those apart; a set cannot produce them.
A remote-tracking ref is refs/remotes/<remote>/<branch>, and
<remote> may itself contain slashes - git remote add gh/upstream
is accepted - so where one segment ends and the other begins is not
recoverable from the refname. Every /-suffix of the tail joins
names rather than guessing: gh/upstream/feat/pushed contributes
upstream/feat/pushed, feat/pushed and pushed. That can only add
names, so its failure is to spare a branch whose name happens to be a
suffix of another ref’s path - never to delete a live one, which
splitting once does. ref_count counts refs and is untouched by it.
The --show-toplevel equality check is what keeps discovery from
walking up: git answers happily from an ancestor repo when repo is
merely nested inside one. It is only meaningful because the helper
above scrubs the env first - with GIT_DIR set, --show-toplevel
reports the working directory and the check passes while the refs
come from elsewhere.