Skip to content

fix(artifact): put binary macro before merge=ours in generated .gitattributes#916

Open
alex-plosceac wants to merge 1 commit into
DeusData:mainfrom
alex-plosceac:fix/artifact-gitattributes-merge-ours
Open

fix(artifact): put binary macro before merge=ours in generated .gitattributes#916
alex-plosceac wants to merge 1 commit into
DeusData:mainfrom
alex-plosceac:fix/artifact-gitattributes-merge-ours

Conversation

@alex-plosceac

@alex-plosceac alex-plosceac commented Jul 6, 2026

Copy link
Copy Markdown

What does this PR do?

Fixes the attribute ordering in the auto-generated .codebase-memory/.gitattributes so the merge=ours conflict prevention it exists for actually engages.

The writer currently emits:

graph.db.zst merge=ours binary

gitattributes apply left to right, and the binary macro expands to -diff -merge -text, so the trailing macro unsets the merge=ours that precedes it:

$ git check-attr merge -- .codebase-memory/graph.db.zst
.codebase-memory/graph.db.zst: merge: unset

Concurrent artifact refreshes on two branches therefore hit a binary merge conflict instead of auto-resolving — the exact failure the generated file's own comment says it prevents. Reordering to graph.db.zst binary merge=ours fixes it:

$ git check-attr merge -- .codebase-memory/graph.db.zst
.codebase-memory/graph.db.zst: merge: ours

-diff and -text from the macro remain in effect.

How this was found: while investigating the v0.8.1 layout memory blow-up on a 155k-node repository (17.6GB peak RSS for a 50k-node layout; full evidence, lldb SIGKILL capture, and measurements confirming main is fixed are in #917), we committed the graph artifact for team bootstrap and noticed check-attr reporting merge: unset on the freshly generated file.

Verification, reproduce-first: extended artifact_gitattributes_created to pin the ordering (asserts the fixed order present, broken order absent). It fails on unmodified main (5914 passed / 1 failed) and passes with this change (5915 / 0, ASan+UBSan build).

Scope notes:

  • The writer is create-only (O_EXCL), so existing repos keep their old file; affected users need a one-line manual edit. Happy to add a fix-up pass if preferred.
  • Even with correct ordering, merge=ours needs merge.ours.driver=true in the clone's git config; the tool sets it where it runs, but teammates' fresh clones won't have it and degrade to a normal conflict. Possibly worth a docs note (out of scope here).

Checklist

  • Every commit is signed off (git commit -s) — required, CI rejects
    unsigned commits (DCO, see CONTRIBUTING.md)
  • Tests pass locally (make -f Makefile.cbm test) — 5915 passed, 0 failed, 1 skipped
  • Lint passes (make -f Makefile.cbm lint-ci) — cppcheck, clang-format, NOLINT whitelist all green
  • New behavior is covered by a test (reproduce-first for bug fixes) — artifact_gitattributes_created extended; RED on main, GREEN with fix

…tributes

gitattributes apply left to right and the binary macro expands to
-diff -merge -text, so the generated line

    graph.db.zst merge=ours binary

leaves the merge attribute UNSET (git check-attr merge reports
"unset"), and concurrent artifact refreshes produce a binary merge
conflict instead of auto-resolving -- the exact failure this file is
generated to prevent. Reordering to

    graph.db.zst binary merge=ours

makes check-attr report merge: ours while keeping -diff/-text intact.

Verified on a real repository: before the reorder git check-attr merge
-- .codebase-memory/graph.db.zst printed "unset"; after, "ours".

Extends artifact_gitattributes_created to pin the ordering so the
regression cannot return.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Alex <plosceac.alexandre@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant