Repository navigation
Expand file tree
/
Copy path.gitattributes
More file actions
108 lines (101 loc) · 6.52 KB
/
Copy path.gitattributes
File metadata and controls
108 lines (101 loc) · 6.52 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
# Repo default: LF in the blob AND in the working tree, for every tracked
# file. tan-cli#364: `feat/v06-batch` was authored largely from a Windows box
# whose `core.autocrlf` is `true`, and 111 files came back CRLF-converted --
# `.github/workflows/release.yml`, `python/tan/cli.py`, `doctor_cmd.py`,
# `flash_cmd.py`, the parity fixtures, whole test modules. Every one of them
# then reads as a full-file replacement in review (a 38-line change to
# `bootstrap.py` rendered as 3668 changed lines) and `git diff --check`
# reported 11,788 findings, so the real diff could not be audited at all.
#
# The specific `text eol=lf` pins below predate this and stay: each one records
# WHY that path must be LF regardless of the default (byte-exact vendoring,
# a script that executes on a customer's machine, a gate anchored on `
`).
# This line is the blanket floor under them, not a replacement for them.
#
# Every tracked file in this repo is text -- .py .yaml .txt .md .json .c
# .conf .exit .yml .sh .toml .h .js .zsh .ps1 .fish .env .bash -- so
# `text=auto` has no binary to misdetect here. Adding a binary asset later
# needs its own `-text` line.
* text=auto eol=lf
# The cross-repo parity scripts byte-compare vendored trees against a fresh LF
# emit from a live alp-sdk checkout. Force LF so a Windows CI checkout
# (autocrlf=true) cannot CRLF-convert them and break byte-exactness.
tests/parity/** text eol=lf
# The Python port's copy of that same tree (it reads its own package data --
# PyInstaller has no `include_str!`). Same reason, plus one more: the two copies
# are byte-diffed against each other by `python/tests/core/test_scaffold.py`, so
# a CRLF conversion of either side alone reds that gate.
python/tan/templates/vendored/** text eol=lf
# Vendored copy of alp-sdk's `tests/fixtures/kconfig-contract/emit-kconfig.
# golden.json` (alp-sdk#894), byte-diffed against the pinned alp-sdk checkout
# by tests/parity/kconfig_fixture_parity.py. Force LF for the same reason as
# the wizard-template vendoring above.
tests/fixtures/kconfig-contract/** text eol=lf
# Vendored copy of alp-sdk's `metadata/bootstrap.json` (alp-sdk#917), byte-
# diffed against the live checkout by tests/parity/bootstrap_manifest_parity.py.
# Same reason again: a Windows checkout with autocrlf=true would CRLF-convert
# it and fail that byte-diff against the LF original.
contract/fixtures/bootstrap/** text eol=lf
# Vendored copy of alp-sdk's `metadata/toolchains.json` (tan-cli#172), byte-
# diffed against the live checkout by tests/parity/toolchain_lock_parity.py.
# Same reason again: a Windows checkout with autocrlf=true would CRLF-convert
# it and fail that byte-diff against the LF original.
contract/fixtures/toolchains/** text eol=lf
# The installers are fetched and executed on a customer's machine. A CRLF
# `install.sh` fails on every POSIX host with `bad interpreter: /usr/bin/env
# sh^M` -- a first-contact failure with a cause that reads like nothing to do
# with line endings. `core.autocrlf=true` (the Windows default, and this
# machine's setting) CRLF-converts it on checkout, so the only thing keeping
# LF in the blob is git's normalise-on-commit; pin it rather than rely on
# every future contributor's config matching.
install.sh text eol=lf
# tan-cli#907, superseded: from 2026-08-11 through 2026-08-30 this line read
# `python/tests/gates/MODULE_SIZE_BUDGET_LOG.md merge=union` (tan-cli#939's
# interim mitigation -- `union` is git's built-in low-level merge driver, no
# `merge.<name>.driver` config needed, and it made a genuinely append-only
# file's real two-branch conflicts resolve themselves: both sides' new lines
# kept, no conflict markers). It is REMOVED, not merely stale: `union` only
# ever fixed the LOCAL `git merge` case. GitHub computes a pull request's own
# mergeable status without applying custom merge drivers at all -- measured on
# PR #971 (tan-cli#907 comment, 2026-08-28: a real `git merge origin/dev` at
# that PR's exact head resolved clean with zero conflict markers, while
# GitHub, polled three times over eight minutes, reported `CONFLICTING` every
# time) -- so a union-attributed file could still show a PR as CONFLICTING in
# the GitHub UI even though a local merge of the same two branches would
# resolve clean -- the mitigation never reached the thing that actually
# blocks a PR. The real
# fix (tan-cli#907) is `python/tests/gates/MODULE_SIZE_BUDGET_LOG.d/`: one new
# file per entry, which needs no merge attribute here at all, because two new,
# differently-named files are trivially compatible under every merge strategy,
# local or GitHub-side (see that directory's own `README.md`). The now-frozen
# `MODULE_SIZE_BUDGET_LOG.md` (no future entry ever lands in it again) is
# plain text with no special attribute, same as any other file that no longer
# changes -- an accidental future edit to it SHOULD conflict or fail its own
# append-only gate, not be silently unioned away.
#
# `module_size_budget.generated.json`, the sibling file that used to sit in
# the same directory, never carried `merge=union` and never could: it was a
# JSON object, and union-merging two JSON documents that both add a trailing
# key can leave two sibling entries with no comma between them (verified:
# `git merge-file --union` on two divergent copies of a trivial
# `{"a":1,"b":2}` produces `"c": 3` directly followed by `"d": 4` with no
# separator, which fails `json.load`). tan-cli#1057 retired that file the
# same way tan-cli#907 retired the single-file ledger above -- one record
# file per measured module under
# `python/tests/gates/module_size_budget.d/`, so two branches touching
# different modules write different paths and have nothing to conflict over,
# with no merge attribute needed here at all. Measured before committing to
# it, over 93 value-changing commits to the old file (4278 pairs): 100% of
# pairs collided under one file, 61.3% would still collide under a
# per-top-level-package split, and 12.9% do under the per-module split with
# the two whole-tree scalars derived rather than stored. That residual 12.9%
# is two branches editing the SAME module, and its correct resolution is
# unchanged: "take either side, then rerun `python
# scripts/regen_module_size_budget.py --merge-resync`" -- never hand-edit a
# value, and never interpolate between two committed numbers. A merge can
# still leave a record semantically STALE with no marker at all (one side's
# edit to a module, the other side's record for it);
# `regen_module_size_budget.py --check` is the backstop for that case, wired
# into CI as its own step (tan-cli#907) rather than left as a command someone
# has to remember to run.