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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
//! Line endings — the part git normally does, which we have to do ourselves.
//!
//! Git converts on the far side of the filter, so for an encrypted path it would
//! always hit ciphertext rather than content. The conversion therefore moves
//! here, and it moves **asymmetrically**:
//!
//! * clean never reads git's configuration. The same file has to yield the same
//! plaintext on every machine, or the ciphertext differs and determinism dies.
//! * smudge does read it. That is the one moment where machines are allowed to
//! differ, and where they should — but only when the configuration asks. Since
//! 2026-08-11 the case where nothing asks writes the stored bytes back
//! unchanged rather than the platform's own ending, so two machines differ
//! because someone chose it and not by default; see [`resolve_output`].
//!
//! Whether a file was normalised at all is recorded in the header's flag bit, so
//! smudge never has to ask `.git-xcrypt` — which also removes a real race, since
//! git does not promise to write `.git-xcrypt` before the files it filters.
use crate;
/// Whether git — and therefore we — would treat this content as binary.
///
/// A byte-for-byte port of git's `gather_stats` plus `convert_is_binary`,
/// measured against git 2.55 rather than taken from documentation. Binary means
/// a NUL byte anywhere, a lone `CR` — one not followed by `LF` — or too many
/// disallowed control characters relative to printable ones.
///
/// The three details that make it a port rather than an approximation, each of
/// which git-xcrypt got wrong before and each of which moves real files across
/// the boundary:
///
/// * `CR` and `LF` are counted as line endings and go into **neither** bucket;
/// * `DEL` (`0x7f`) counts as non-printable, despite being above `0x20`;
/// * of the bytes below `0x20` only `BS`, `TAB`, `FF` and `ESC` are forgiven;
/// * a **trailing `SUB`** (`0x1a`, the DOS end-of-file marker) is taken back off
/// the non-printable count after the scan. One byte, only the last one.
///
/// Bytes at or above `0x80` count as printable, which is why UTF-8 text is
/// recognised as text. The whole content is scanned; the 8000-byte window
/// belongs to a different heuristic, the one `git diff` uses to print
/// `Binary files differ`.
///
/// The lone-`CR` rule is not decoration. Without it, content such as
/// `a\r\r\nb` normalises to `a\r\nb`, which normalises again to `a\nb` — so the
/// conversion is not closed over its own output, the working tree comes back
/// different after a checkout and `git status` reports a file nobody edited.
/// Git avoids that the same way, by declining to convert at all.
///
/// This rule is **frozen with the format from 2026-08-04**, and not before: the
/// trailing-`SUB` correction landed on that date (roadmap S-08), deliberately
/// ahead of the first release. Changing it moves the text/binary boundary, so
/// every file that crosses the boundary encrypts differently — after a release
/// that stops being a fix and becomes a new `suite`.
/// Whether the content should be normalised, given its declared mode.
///
/// Unlike git, the answer never depends on the index. Git keeps CRLF for a file
/// that entered the repository with it, even after `core.autocrlf` is switched
/// on — which makes its verdict a function of history, not content. Ours has to
/// be a pure function of content or the same file encrypts differently depending
/// on where it has been.
/// Replaces every `CRLF` with `LF`.
///
/// A lone `CR` is left alone: it is not a line ending git would have produced,
/// and rewriting it would corrupt content that merely happens to contain the
/// byte.
///
/// **Not idempotent in general** — `\r\r\n` collapses to `\r\n` and would
/// collapse again to `\n` on a second pass, exactly as git's own conversion
/// does. Under `text=auto`, which is the default and so the mode almost every
/// path is in, that never happens: content carrying a lone `CR` is classified
/// binary by [`looks_binary`] and is never normalised at all.
///
/// **An explicit `text` bypasses that classifier**, so a path declared
/// `secrets/*.sh text` whose content holds `\r\r\n` does not round-trip: clean
/// stores `\r\n`, smudge writes it back, and the next clean collapses it again,
/// so `git status` reports the file as modified until it is added again — which
/// stores the collapsed bytes. Git does the same thing with an explicit `text`
/// attribute, and measured on 2.55 it does **not** warn about it even with
/// `core.safecrlf=warn`.
///
/// That is not the only shape, and not the worst one. Mixed `CRLF` and lone `LF`
/// is normalised under plain `text=auto` too, so the default mode loses the
/// distinction as well — and there `git status` stays *clean* while the working
/// tree changes, because the new bytes normalise to the same plaintext.
/// [`survives_the_round_trip`] answers for both, and the filter warns; Open
/// Decision 8 in `context/foundation/zalozenia.md` closed on 2026-08-06.
/// Recorded here rather than claimed away, because an earlier version of this
/// comment asserted the invariant held everywhere.
/// Rewrites LF as CRLF.
/// What the working tree should receive, given the declaration and git's config.
///
/// The table is measured, not guessed: `autocrlf=true` yields CRLF and ignores
/// `core.eol`, `autocrlf=input` yields LF and ignores it too, and only
/// `autocrlf=false` lets `core.eol` decide.
///
/// **One row deliberately departs from git's own table, since 2026-08-11: with
/// `core.autocrlf` false or unset and `core.eol` unset, this writes the stored
/// bytes back unchanged rather than the platform's own ending.** That is the
/// configuration in which git converts *nothing*, and until this change
/// declaring a path secret opted it into a conversion the same file would never
/// have received while stored in the clear. Measured on git 2.55, two throwaway
/// repositories, a declared path and an undeclared one holding identical bytes:
///
/// | config | undeclared, git decides | declared, we decided | agreed? |
/// | --- | --- | --- | --- |
/// | `autocrlf=true` | `LF` in, `CRLF` out | `CRLF` out | yes |
/// | `autocrlf=input` | `CRLF` in, `LF` out | `LF` out | yes |
/// | `autocrlf=false`, `eol` unset | `LF` in, `LF` out | **`CRLF` out** | **no** |
/// | `autocrlf=false`, `eol=lf` | `CRLF` in, `CRLF` out | **`LF` out** | **no** |
///
/// `git status` was clean in all four, so nothing signalled either mismatch. The
/// third row is what this arm fixes; the fourth is the check-in half — `clean`
/// normalises before the header can record which ending was there — and no
/// choice made here can bring that back, so it stays a documented limit rather
/// than a fixed one. What the change does buy for it is that the answer stops
/// depending on the platform: after this, a declared path on Windows and on
/// Linux receives identical bytes unless something explicitly asks otherwise,
/// which is what §Non-Functional Requirements means by no differences across
/// machines.
///
/// An explicit `core.eol=native` still selects the platform's ending, because
/// that is a user asking for it rather than a default nobody chose, and it is
/// the way back to the previous behaviour without editing `.git-xcrypt`. So is
/// `eol=native` on the pattern, which outranks all of this.
///
/// Nothing here touches a stored byte: `clean` never reads configuration, the
/// ciphertext is unchanged, and whatever this writes normalises back to the same
/// plaintext — so the repository stays clean across the change.
/// Whether **git** would write `CRLF` into the working tree for a path it
/// converts itself.
///
/// Git's `text_eol_is_crlf`: `core.autocrlf` first, `core.eol` only while it is
/// false, the platform when neither says anything. It is asked about a different
/// subject than [`resolve_output`] — not "what should we write" but "is git
/// about to expand `LF` to `CRLF` in bytes it hands us" — and since 2026-08-11
/// the two answers differ in one row, so it computes its own rather than
/// borrowing. With `core.eol` unset git's default *is* `native`, and a path some
/// foreign line declared `text` really does get expanded; reading our own
/// narrower answer here would have made this say "git left it alone" about a
/// checkout that had just eaten the `CR` bytes out of a ciphertext, which is the
/// one question this function exists to answer.
///
/// That question only comes up on the smudge path, and only once an
/// authentication tag has already failed. Git's check-out order is blob, then
/// git's conversion, then smudge, so on a path some attribute line pulled out
/// from under the managed `-text`, the tag is handed bytes that were never
/// stored — and the file is fine while the message says it is not.
/// The platform-independent core, for the same reason [`apply_where`] has one.
/// Whether a configuration value is one of git's spellings of true.
///
/// Shared with `status`, which has to read `filter.git-xcrypt.required` by the
/// same rule: two answers to "is this git boolean true" is one answer too many.
/// Applies a resolved line-ending mode to content that was normalised to LF.
/// The platform-independent core, so both arms are testable from either machine.
///
/// `native_is_crlf` is `cfg!(windows)` in production and an argument here for the
/// same reason `repo::with_separator` takes a separator: this arm decides the
/// bytes that land in a **Windows** working tree, and the development machine is
/// not Windows, so without the parameter it would be covered by CI alone.
///
/// It is the smudge half of the asymmetry this module exists for — clean never
/// reads the platform, smudge is the one place that may — so the invariant worth
/// pinning is that the two still meet: whatever this writes out has to normalise
/// back to exactly what came in, or the same file yields a different blob on
/// Windows and `git status` reports a file nobody edited.
/// Whether the working tree's own bytes can still be recovered from what
/// `clean` is about to store.
///
/// Normalisation maps several working trees onto one plaintext, so for some
/// content the original is simply gone. This asks about *that* — whether the
/// information survives — and deliberately **not** whether the bytes change.
/// The distinction is the whole design of this predicate, and it is where we
/// part company with git's `core.safecrlf`.
///
/// Git asks the wider question: it counts `CRLF` and lone `LF` before and after
/// a simulated round trip, so on a machine with `core.autocrlf=true` an ordinary
/// LF-only file warns — measured on 2.55, `* text=auto` and `a\nb\nc\n` give
/// `LF will be replaced by CRLF the next time Git touches it`. Git can afford
/// that because `safecrlf` defaults to **false**; the warning is opt-in. Ours is
/// always on and has no knob, so the wider question would put a line on `stderr`
/// for every text file in every Windows checkout — and a warning that fires on
/// healthy content is worse than none, because it teaches the reader to skip the
/// two that mean something.
///
/// Recoverable means some line-ending mode reproduces the original, which is the
/// question a *uniform* file always answers yes to and the two lossy shapes
/// always answer no to. Measured on git 2.55, verdict = working tree compared
/// byte for byte after `add`, `commit`, `rm`, `checkout`:
///
/// | content | git, `safecrlf=warn` | this |
/// | --- | --- | --- |
/// | `a\nb\nc\n`, out `CRLF` | warns | quiet — comes back as uniform `CRLF`, stable from then on |
/// | `a\r\nb\r\nc\r\n`, out `LF` | warns | quiet — mirror image |
/// | `a\r\nb\nc\r\n` mixed | warns | **catches** |
/// | `a\r\r\nb` under `text` | **silent**, byte lost | **catches** |
/// | `a\r\r\nb` under `auto` | silent, untouched | quiet — agrees, [`looks_binary`] declines to convert |
///
/// Git misses the fourth row because its two counters cannot see a lone `CR`:
/// one `CRLF` goes in and one comes out, so the totals agree while a byte is
/// gone.
///
/// Being a question about information rather than bytes, the answer needs no
/// [`EolMode`] and reads no configuration — so it is the same on every machine,
/// which is what keeps it from being one more thing that behaves differently on
/// Windows.
///
/// The two lossy shapes fail differently and a caller must not promise either:
/// mixed endings come back changed with `git status` **clean**, because the next
/// clean normalises the new bytes to the plaintext already stored; `CR` before
/// `CRLF` collapses one byte further on each pass and does show up as modified.