Tags: bobisme/maw
Tags
chore(ci): fix crates.io publish workflow + bump to 0.60.1 - Add maw-lfs to publish order (required dep of maw-git via default lfs feature) - Use pushed git tag to derive version dynamically (was hardcoded 0.54.0) - Target maw-workspaces explicitly at the final publish step - Add publish metadata to maw-assurance (description, license, keywords, categories) No library or binary behavior change since v0.60.0.
chore: bump version to 0.59.0 — hardening release (bn-opm7) Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
fix(merge): conflict detection missed large files and embedded marker… …s (bn-3h90 follow-up) Two tightly related bugs that made v0.58.3's Bug 1 fix incomplete: Bug A: file_has_conflict_markers only read the first 256KB of each file. Repos with large append-only files (e.g., tests/cve-registry/manifest.toml with thousands of entries) had conflict markers past that offset that were silently invisible to ws resolve --list. The v0.58.3 reconcile logic then cleared the rebase_conflict_count counter on a workspace that actually had real unresolved conflicts. Fix: stream the entire file line-by-line (bounded at 256MB for safety). Markers anywhere in the file are now reliably detected. Bug B: ws conflicts ran the merge engine's PREPARE+BUILD in a temp dir for a single workspace. With only one source, the engine sees a clean 1-side modification — marker-laden content (from sync --rebase committing markers into HEAD) looked like normal content and was reported "no conflicts found". Users saw three tools agree the workspace was clean while HEAD actually had markers. Fix: ws conflicts now ALSO scans each workspace's worktree for embedded markers and surfaces them as a separate category. ws merge uses the same scan as an unconditional pre-flight — not only when rebase_conflict_count > 0. The worktree is now the authoritative signal; the counter is advisory metadata that gets reconciled. Added 4 regression tests: - find_conflicted_files_detects_markers_past_256kb - ws_merge_refuses_workspace_with_embedded_markers_in_large_file - ws_conflicts_reports_embedded_markers_when_engine_is_clean - file_has_conflict_markers_skips_files_over_256mb Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
fix(merge,destroy): phantom rebase conflict + orphaned oplog head (bn…
…-3h90)
Bug 1: ws merge refused to proceed when a source workspace had a stale
rebase_conflict_count in metadata, even after the user resolved the
rebase conflict with plain git (add + commit). ws conflicts, ws resolve
--list, and ws sync all reported the workspace clean — only ws merge
trusted the stale counter.
Fix: ws merge now reconciles the counter against the worktree before
blocking. If no conflict markers exist, the counter is auto-cleared
and the merge proceeds. ws resolve --list does the same reconciliation
as a side effect. --force is now actually implemented as an escape
hatch (previously advertised in the error message but didn't exist).
Bug 2: ws destroy deleted refs/manifold/ws/<name> and
refs/manifold/epoch/ws/<name> but NOT refs/manifold/head/<name> (the
oplog head ref). On recreate with the same name, the new workspace
inherited the destroyed workspace's oplog chain, including checkpoint
annotations referencing patch-set blobs from the dead snapshot.
Subsequent merges spammed:
WARNING: checkpoint write skipped for workspace 'default':
checkpoint: op log read error: `git cat-file -p <blob>` failed
Fix: ws destroy now deletes the head ref too. Recovery is unaffected
because recovery data lives under refs/manifold/recovery/<name>/.
Also added:
- ws repair-oplog <name> recovery command (with --dry-run) for repos
already corrupted by the pre-fix destroy bug. Archives the head ref
under refs/manifold/archive/head/<name>/<ts> and deletes it so the
next operation starts fresh.
- Damaged-chain warning is now logged once per workspace per session
instead of on every merge.
Added 5 regression tests in tests/merge_rebase_reconcile.rs covering
both bugs plus the --force flag and the resolve-list reconciliation.
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
fix(merge): honor .gitattributes merge drivers (union, ours, binary) Files with merge=union in .gitattributes were still getting diff3 conflict markers during maw ws merge. Maw had never consulted .gitattributes merge drivers in either the BUILD phase (which shelled out to git merge-file -p --diff3 on raw content) or the stash replay path (which used gix's default text driver). Both paths now load .gitattributes from the merge base and dispatch per-path: - merge=union → lines concatenated, no markers (append-only logs, changelogs) - merge=ours → first workspace's side wins for conflict hunks - merge=binary → any divergence reported as conflict (no text merge) - unknown custom drivers → safely fall back to diff3 Implementation: - maw-lfs AttrsMatcher now tracks both filter=lfs and merge=<driver> - New AttrsMatcher::merge_driver(path), from_gix_tree(), from_gix_head() - maw-git merge_text_with_style() using gix's Conflict::ResolveWithUnion - GixRepo::load_gitattributes_at_commit() for loading attrs at a commit - resolve.rs checks merge driver before diff3, short-circuits for union/ours via gitattr_driver_merge() and refuses text merge for binary - build_phase.rs loads attrs at the merge base and threads through - working_copy.rs stash replay path does the same maw-lfs is now an unconditional dependency of maw-cli and the root crate. The lfs feature flag is kept as a no-op for backward compat. Adds 10 integration tests (tests/merge_gitattributes.rs) covering the exact bones/events scenario plus nested .gitattributes, multi-workspace unions, the bones events scenario that triggered the report, and fallthrough for unknown drivers. Plus 11 attrs matcher unit tests and 5 new merge module tests. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
PreviousNext