Three reported usability defects: --only separator, shared-tree scope, error banners on working paths
Three usability defects reported verbatim by pushing lanes during OPS-173 intake. Each is small; together they are why the script reads as adversarial. 1. --only IS COMMA-SEPARATED AND A SPACE SILENTLY CHANGES SCOPE. gitpush.sh:790 splits with IFS=',' read -r -a. coder02-terra-cc: 'a space instead of a comma silently changes the scope of the commit', and calls hand-assembling that list the single highest-friction part of their work. A separator mistake must be an error, not a different commit. 2. --only BOUNDS THE COMMIT, NOT THE TREE - AND TWO AGENTS SHARE ONE TREE. This is why the pre-push raw git that Elazar objects to exists on terra, and it is not about the bump. coder02-terra-cc: 'my lane is db/, pm/, shared/ and agents/, and I am explicitly barred from pushing src/, while a second agent pushes src/ in the same working tree. So I check the tree because --only bounds what gets COMMITTED and does not bound what is already staged or what the other lane left dirty.' They run git status --porcelain before and git status --porcelain src/ plus git log --oneline -1 origin/main after. coder-mars-cc solves the same problem with flock -w 600 on a lock file. Neither is working around the script's bugs - they are supplying isolation it does not offer. The per-stack scripts should either verify the tree outside --only is clean and say what it found, or state plainly that they do not, so nobody has to discover it. 3. THE LOUDEST BANNER IN THE SCRIPT FIRES ON A SUPPORTED PATH. gitpush.sh:1855-1861 prints a red boxed 'ERROR: No bump flag provided' and then proceeds with --patch anyway. coder-terra-ca's normal push omits the flag. An error banner on a path that works trains every reader to ignore error banners - and this file has real ones. Same class: coder-mars-cc reports gitpush.sh aborting EXIT=1 on the first run after a GITPUSH_INFO_VERSION marker sync, needing a plain re-run, 'it reads like a failure'. A required re-run is a normal outcome and must not be spelled as an abort.
Activity
-
parent=#3117
-
MEASURED 2026-10-05 (bin-venus-cc), all three sites, against the live tree. COVERAGE CAVEAT FIRST: the 2408-line monolith these were filed against no longer exists (7cf82ee, v5.0, 2810 -> 308 lines), so the original reproductions are UNREACHABLE. This is a reading of the current behaviour, not a replay of the three reports. (1) --only separator: now stated explicitly where a user meets it - gitpush.sh:27 'gitpush.sh --only a,b [msg]' and the error path at :86 'Run: gitpush.sh --only <comma-separated paths> "message"'. :90 refuses an EMPTY --only before anything runs rather than at the old stage step, which is the stricter half and is commented as a deliberate move. (2) shared-tree scope: named at the point of refusal, gitpush.sh:85 - 'This checkout is shared, so git add -A would sweep other lanes' files.' The rationale lives with the selection library (commit-selection-lib.sh:6 and :35), including the v4.14 ordering defect where staging before the hook could publish another lane's in-flight files under this lane's commit. (3) error banner on a working path: GONE. The red boxed 'ERROR: No bump flag provided' that then bumped at patch anyway is removed with the monolith - gitpushnextjs.sh:77 and gitpushrepo.sh:26 both record its removal, and gitpushnextjs.sh makes the flag's absence a real abort instead. The one surviving instance is the CORRECT shape: gitdeploydev.sh:317 prints a YELLOW 'No bump flag provided; defaulting to --patch' - a notice matching what the code then does, which is exactly what this row asked for. The defect was a RED ERROR banner on a succeeding path, not the message.
-
Done. All three reported defects are resolved in the live tree; two by explicit handling in gitpush.sh/commit-selection-lib.sh, the third by the monolith's retirement. Closed with the caveat recorded above: the original repros are unreachable, so this is a current-behaviour verdict.