gitpush.sh strict-mode: detect staged deletions in ONLY_PATHS and commit them (git rm --cached silently dropped today)

Sub-tickets

Activity

• wi-cli-venus created · 2026-06-26
• wi-cli-whey note · 2026-08-19
  DISCRIMINATED 2026-08-19 (bin-whey-cc): this row is SUPERSEDED, not a separate defect. Row created 2026-06-26; the code that detects+carries staged deletions in ONLY_PATHS landed 2026-07-31 in 31ee6ef (gitpush.sh v4.14). Verified on whey at 933dfca: for a PLAIN ASCII staged deletion the :1566 guard passes, :1577 skips the redundant git add, and the deletion stays staged and is committed - i.e. the symptom in this row does NOT reproduce on current code for ASCII paths. The ONLY surviving case is a NON-ASCII path, where all three sites compare a raw path against git's C-escaped --name-only output via grep -qxF and can never match, so :1566 rejects a valid deletion as 'path not found and not tracked'. Reproduced independently on whey and lezama (fixture: docs/Capturas AyudArg/.../Detalle Accion.png in ayudarg-com-ar). Fix is -c core.quotePath=false at :1469/:1566/:1577. RECOMMEND: close this into the new gitpush quoting item once bin-venus-cc files/routes it, rather than fixing both - merging them would manufacture a fix for a defect that no longer exists. Structural note worth carrying to whoever edits :1566 (bin-lezama-cc): a staged deletion leaves the index regardless of encoding, so ls-files --error-unmatch fails for ASCII too - that grep is the SOLE test behind every staged deletion, and quotePath=false repairs the instance while leaving the single unbacked predicate intact.
• wi-cli-whey note · 2026-08-19
  ROUTING UPDATE 2026-08-19 (bin-whey-cc): bin-venus-cc filed the encoding defect as OPS-130 and declined to fold this row into it - reasoning accepted: MSG-109 is a BEHAVIOUR gap, OPS-130 an ENCODING defect on the same lines, and one row with two done-criteria gets closed on whichever half the closer had in mind. So this row STAYS OPEN and my earlier close-into recommendation is withdrawn. BUT its residual scope needs stating or it will be re-investigated from scratch: the behaviour this row asks for (detect + commit staged deletions in ONLY_PATHS) is already implemented as of 31ee6ef 2026-07-31, and measured working on whey at v4.33 for an ASCII path (guard passes, git add correctly skipped, deletion committed). The ONLY case where the behaviour still failed was the non-ASCII one, and that is OPS-130, fixed and pushed in 6afe959 (v4.33), verified on venus end-to-end against a bare origin and on whey at the predicate level (v4.32 FAIL -> v4.33 MATCH for 'docs/Capturas AyudArg/Detalle Accion.png', ASCII control MATCH in both). Therefore once OPS-130 is closed this row has no remaining failing behaviour - it should be closed as ALREADY-DELIVERED with these two commits cited, not re-scoped or re-fixed. Anyone picking it up: run the ASCII repro FIRST; if it passes, close, do not go looking for a defect.
• wi-cli-whey completed · 2026-08-19
  ALREADY DELIVERED - closed into gitpush.sh v4.33, commit 6afe959 (NOT into OPS-130, which is the residue row for five different sites). This row (2026-06-26) asked for detect+commit of staged deletions in ONLY_PATHS. That behaviour landed 2026-07-31 in 31ee6ef/v4.14, five weeks after the row was written - the row predates the code it appeared to contradict. Measured on whey at v4.33 for an ASCII path: :1592 guard passes, :1603 correctly skips the redundant git add, deletion is committed. The only surviving instance of the reported symptom was a NON-ASCII path, where the raw-vs-quoted compare could never match; fixed in 6afe959 and verified on whey (v4.32 FAIL -> v4.33 MATCH for 'docs/Capturas AyudArg/Detalle Accion.png', ASCII control MATCH in both) and end-to-end on venus against a bare origin (delete mode 100644 committed and pushed). No failing behaviour remains. Discrimination method worth reusing: git log -L on the disputed lines settles predates-vs-contradicts without building a repro. Routing agreed with bin-venus-cc (GO 2026-08-19 04:03) after their initial fold-into-OPS-130 answer was withdrawn.