54 lines
2.3 KiB
Markdown
54 lines
2.3 KiB
Markdown
 
|
---
|
||
|
|
type: issue
|
||
|
|
id: "0053"
|
||
|
|
status: open
|
||
|
|
created: 2026-08-15
|
||
|
|
milestone: M2
|
||
|
|
priority: low
|
||
|
|
area: infrastructure
|
||
|
|
related:
|
||
|
|
- "docs/adr/0009-commit-konventionen-und-historien-anonymisierung.md"
|
||
|
|
---
|
||
|
|
# Historien-Durchgang: acht nicht-kanonische Commits mitziehen
|
||
|
|
|
||
|
|
## Problem / Motivation
|
||
|
|
|
||
|
|
Acht Commits vom 14./15.08.2026 tragen `sorb <sorb.business@gmail.com>` statt der kanonischen
|
||
|
|
Identität `Thore Cimbal <cfx@riot.8shield.net>` (ADR-0009). Entstanden in einer Agenten-Session:
|
||
|
|
in frisch geklonten Repos wurde `user.email` von Hand gesetzt — ausgerechnet kurz **nachdem**
|
||
|
|
dieselbe Session die kanonische Identität in `AGENTS.md` ausgeschrieben hatte (#0027/W7).
|
||
|
|
|
||
|
|
Die betroffenen Commits:
|
||
|
|
|
||
|
|
| Repo | Commits |
|
||
|
|
|---|---|
|
||
|
|
| `threadnet-operating` | `1bbff5e7`, `4cb9bfb2`, `e0808bad`, `e9c13dcf` |
|
||
|
|
| `notfallhandbuch` | `5e398e73`, `6ff291d0`, `a55e6ee2` |
|
||
|
|
| `thread-net-git` | `8d089e23` |
|
||
|
|
|
||
|
|
**Entscheidung sorb 2026-08-15:** *nicht* jetzt einzeln umschreiben, sondern **beim nächsten
|
||
|
|
ohnehin anstehenden Historien-Durchgang mitziehen**. Ein Force-Push über zwei Repos für acht
|
||
|
|
Commits steht in keinem Verhältnis — der Inhalt ist korrekt, nur das Namensschild ist falsch.
|
||
|
|
|
||
|
|
## Acceptance
|
||
|
|
|
||
|
|
- Die acht Commits tragen die kanonische Identität (ADR-0009).
|
||
|
|
- Die Auflage aus ADR-0009 ist erfüllt: **alt→neu-Zuordnung** dokumentiert, analog zu
|
||
|
|
`docs/sources/migration/commit-zuordnung-2026-08-07.md`.
|
||
|
|
- `gruppenpruefung.py` meldet keine `nicht-kanonische Identität` mehr.
|
||
|
|
|
||
|
|
## Notes
|
||
|
|
|
||
|
|
**Warum dieses Issue existiert, obwohl die Sache vertagt ist:** `gruppenpruefung.py` meldet die
|
||
|
|
acht Befunde bei *jedem* Lauf. Ohne einen dokumentierten Grund fängt die nächste Session an,
|
||
|
|
sie zu „reparieren" — oder, schlimmer, gewöhnt sich an rote Befunde. Genau das ist am selben Tag
|
||
|
|
beim `TargetDown`-Dauerfeuer aus #0002 passiert. Die Vertagung ist eine Entscheidung, kein
|
||
|
|
Versehen, und gehört deshalb sichtbar abgelegt.
|
||
|
|
|
||
|
|
**Vorbeugung (der eigentliche Punkt):** Die Ursache war ein `git config user.email` von Hand in
|
||
|
|
einem frischen Klon. Dass die Regel eine Stunde vorher aufgeschrieben wurde, hat sie nicht
|
||
|
|
verhindert — dieselbe Lehre wie beim Bindmount (#0027/W6-Klasse). Wirksam wäre etwas
|
||
|
|
Strukturelles statt mehr Sorgfalt, z.B. ein `[includeIf]`-Block in der globalen `.gitconfig`, der
|
||
|
|
die Identität für Klone der Gruppe automatisch setzt, sodass sie gar nicht erst von Hand gesetzt
|
||
|
|
werden muss.
|