Summary
lib_git.sh re-derives "the repo's default branch" from scratch in two places, with different tie-break order.
Details
lib/bash/git/lib_git.sh:13-52 (base_git_detect_default_branch, public) checks origin/main OR heads/main together before falling to origin/master/heads/master.
lib/bash/git/lib_git.sh:241-281 (__base_bash_libs_git_expected_update_branch__, used internally by base_git_update_repo) checks origin/main, then origin/master, then heads/main, then heads/master.
Impact
For a repo with refs/remotes/origin/master and refs/heads/main both present (no origin/HEAD symref, no origin/main), the public function returns main while base_git_update_repo internally resolves master — inconsistent results for the same repo state depending on which function a caller uses.
Suggested fix
Have base_git_update_repo call base_git_detect_default_branch (or extract one shared helper) instead of maintaining a second copy of the fallback chain.
Summary
lib_git.shre-derives "the repo's default branch" from scratch in two places, with different tie-break order.Details
lib/bash/git/lib_git.sh:13-52(base_git_detect_default_branch, public) checksorigin/mainORheads/maintogether before falling toorigin/master/heads/master.lib/bash/git/lib_git.sh:241-281(__base_bash_libs_git_expected_update_branch__, used internally bybase_git_update_repo) checksorigin/main, thenorigin/master, thenheads/main, thenheads/master.Impact
For a repo with
refs/remotes/origin/masterandrefs/heads/mainboth present (noorigin/HEADsymref, noorigin/main), the public function returnsmainwhilebase_git_update_repointernally resolvesmaster— inconsistent results for the same repo state depending on which function a caller uses.Suggested fix
Have
base_git_update_repocallbase_git_detect_default_branch(or extract one shared helper) instead of maintaining a second copy of the fallback chain.