fix(git-remote): move --no-recurse-submodules from global to per-command args#985
Open
kyledeanjackson wants to merge 2 commits into
Open
fix(git-remote): move --no-recurse-submodules from global to per-command args#985kyledeanjackson wants to merge 2 commits into
kyledeanjackson wants to merge 2 commits into
Conversation
…and args Bug: GIT_SSRF_FLAGS placed --no-recurse-submodules in the global-options slot (before the subcommand). On git ≥2.43 this fails with: unknown option: --no-recurse-submodules git accepts --no-recurse-submodules only as a per-command option for clone / pull / fetch — not as a top-level git option. The previous placement happened to work on older git versions that were more lenient about flag position, but breaks on Ubuntu 24.04's git 2.43.0 (and on modern macOS git). Fix: - Drop --no-recurse-submodules from GIT_SSRF_FLAGS - Append it explicitly to the clone args after 'clone' - Append it explicitly to the pull args after '--ff-only' Net result: same submodule-recursion guarantee, with correct flag placement that works on git 2.43+. Discovered while upgrading BH-DevServer to gbrain v0.33.2 — first cycle of lattice-autopilot post-restart failed sync.git_pull on all three sources (bh-brain, bh-vault, bh-studio-general) with the unknown-option error. Pull command exec'd directly via execFileSync confirmed the placement was the cause. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ink.extra_dirs config Bug context: the upstream DIR_PATTERN is a hard-coded alternation of canonical dir names (people, companies, meetings, ...). Sites with custom slug layouts — numbered dirs like '03-ventures'/'06-people'/'07-decisions', or shorthand wikilink aliases like 'venture/'/'person/'/'decision/' — have ZERO of their entries match the whitelist, so 'gbrain extract links --source db' produces 0 links across N pages and the brain reports brain score 46/100 with link_density_score 0 / no_orphans_score 0 (every page orphaned). This is the symptom BHSOFM-48 captured in our deployment (0 links / 599 pages pre-upgrade, 0 links / 735 pages post-upgrade to v0.33.2 — the v0.32.8 'multi-source bug class extermination' addressed cross-source resolution, NOT this regex). Fix (config-driven, default behavior unchanged): - Introduce DEFAULT_ENTITY_DIRS as the canonical-dirs export - Add buildDirPattern(extraDirs) + buildEntityRegexes(extraDirs) factories that build the regex bundle from default ∪ extras - Add getAutoLinkExtraDirs(engine) helper that reads auto_link.extra_dirs from engine config — supports JSON array string or comma-separated - Refactor extractEntityRefs + extractPageLinks to accept optional extras - Wire callers (extract.ts extractLinksFromDB, operations.ts put_page autolink path) to fetch from config + pass through Backward compat: - Module-level constants ENTITY_REF_RE / WIKILINK_RE / QUALIFIED_WIKILINK_RE retained, built from default dirs only — same behavior as before for any direct importer - extractEntityRefs / extractPageLinks signatures backward-compat (extras is optional); callers that don't pass it get default behavior - Config key not set = default behavior (no regression for non-BH users) For BH: gbrain config set auto_link.extra_dirs '["03-ventures","06-people","07-decisions","08-writing","00-inbox","02-being-human","04-projects","05-research","venture","decision","person","research","writing"]' Then 'gbrain extract links --source db' should produce >0 links and link_density_score should improve. Upstream PR forthcoming to garrytan/gbrain — solves the same class of problem for any user with custom dir layouts. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Author
|
Adding a second commit to this branch — Same scope, different file. Full description in the commit message. Happy to split into two separate PRs if you'd prefer — the changes are independent (different files, different bug class). Let me know. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
GIT_SSRF_FLAGSinsrc/core/git-remote.tsplaces--no-recurse-submodulesin the global-options slot (before the subcommand). On git ≥2.43 this fails:--no-recurse-submodulesis a per-command option forclone/pull/fetchonly, not a top-level git flag. Older git versions were more lenient about flag position; modern git (2.43+, default on Ubuntu 24.04 and current macOS) enforces strict placement.Repro
Reproduces on git 2.43.0 / Ubuntu 24.04 LTS on every
gbrain syncoperation. The error surfaces as:Found while upgrading BH-DevServer (Ubuntu 24.04, git 2.43.0) to v0.33.2 — every autopilot cycle's sync phase reported failed git pull on all federated sources. Cycle completed (embed --stale still ran) but staleness detection from upstream commits was bypassed.
Fix
--no-recurse-submodulesfromGIT_SSRF_FLAGS'clone')'--ff-only')Net result: same submodule-recursion safety guarantee, with correct flag placement that works on git 2.43+.
Testing
Verified locally:
sync.git_pull start→sync.git_pull done <N>ms(success) across 3 federated sources on dev-server post-fix. Pre-fix all three failed in <10ms with the unknown-option error.