Du erstellst Commits mit Text wo alles in einer Wurst ist. Bitte zukünftig vermeiden. bisschen mehr Struktur (Absätze, Aufzählungen, etc.)
Ist es auch möglich schon vorhandene Commit-Text zu überarbeiten?
<img width="1465" alt="image.png" src="attachments/f2c152fb-1df9-4539-9f41-925de97bb921">
Du erstellst Commits mit Text wo alles in einer Wurst ist. Bitte zukünftig vermeiden. bisschen mehr Struktur (Absätze, Aufzählungen, etc.)
Ist es auch möglich schon vorhandene Commit-Text zu überarbeiten?
Umgesetzt — ab jetzt gilt die Regel, die History bleibt unangetastet.
Der Befund, gemessen an der echten History
Messung
Wert
Commits im Repo
259
davon mit einem Body
0
Betreff über 72 Zeichen
126
Betreff über 200 Zeichen
43
Betreff über 500 Zeichen
31
längster Betreff
3316 Zeichen (cb1804d)
Das Wiki-Repo hat dasselbe Muster. Jede Log-Ansicht schneidet an der ersten Zeile ab — git log --oneline, die Gitea-Historie, der Viewer im Screenshot. Eine 3316-Zeichen-Zeile ist damit nicht unschön, sondern unlesbar.
Die Regel
Steht im Wiki unter Development → Commit messages (639f190), dazu in der Projektnotiz und in der globalen Memory, damit sie in jedem Repo gilt:
Erste Zeile = eigener Betreff, ein Satz, höchstens 72 Zeichen, Präsens, was der Nutzer davon hat, Issue-Nummer am Ende. Dann eine Leerzeile.
Rumpf in Absätzen und Aufzählungen, auf 72 Spalten umgebrochen: erst ein Absatz zum Warum, dann ein Punkt je Baustein, Entscheidung oder Abweichung, dann die Funde, zum Schluss ein Tests:-Block mit den gemessenen Zahlen.
Keine Semikolon-Ketten. Ein Gedanke, ein Satz.
Technisch der eigentliche Auslöser: die Nachricht kam aus einem einzigen -m. Künftig git commit -F <datei> oder ein -m je Absatz.
Bestehende Texte: nicht angefasst
Entscheidung so getroffen, nachdem ich die Kosten gemessen habe: 348 echte Commit-Hashes dieses Repos stehen in 193 Issues und Kommentaren (alle 376 Issue- und Kommentartexte durchsucht, die Treffer gegen die echte Hash-Liste geprüft), dazu die Fußzeilen der importierten Notizen und die Hashes im Wiki. Ein filter-repo plus Force-Push würde jeden dieser Hashes ändern, und Gitea verlinkt sie heute automatisch — danach zeigt keiner mehr irgendwohin. Die Spur von Issue zu Code ist das, was die alten Nachrichten überhaupt brauchbar macht.
Also: kein filter-repo, kein Force-Push. Die Regel gilt nur nach vorne.
Der erste Beleg
Der Wiki-Commit 639f190 ist selbst im neuen Format geschrieben (Betreff 45 Zeichen, Leerzeile, Absätze, Tests:-Zeile), ebenso die Commits zu #129 Etappe 3, die gerade entstehen — Betreff 57 Zeichen statt 3316.
Umgesetzt — ab jetzt gilt die Regel, die History bleibt unangetastet.
## Der Befund, gemessen an der echten History
| Messung | Wert |
|---|---|
| Commits im Repo | 259 |
| davon mit einem Body | **0** |
| Betreff über 72 Zeichen | 126 |
| Betreff über 200 Zeichen | 43 |
| Betreff über 500 Zeichen | 31 |
| längster Betreff | **3316 Zeichen** (`cb1804d`) |
Das Wiki-Repo hat dasselbe Muster. Jede Log-Ansicht schneidet an der ersten Zeile ab — `git log --oneline`, die Gitea-Historie, der Viewer im Screenshot. Eine 3316-Zeichen-Zeile ist damit nicht unschön, sondern unlesbar.
## Die Regel
Steht im Wiki unter **Development → Commit messages** (`639f190`), dazu in der Projektnotiz und in der globalen Memory, damit sie in jedem Repo gilt:
- **Erste Zeile = eigener Betreff**, ein Satz, **höchstens 72 Zeichen**, Präsens, was der Nutzer davon hat, Issue-Nummer am Ende. Dann eine **Leerzeile**.
- **Rumpf in Absätzen und Aufzählungen**, auf 72 Spalten umgebrochen: erst ein Absatz zum *Warum*, dann ein Punkt je Baustein, Entscheidung oder Abweichung, dann die Funde, zum Schluss ein `Tests:`-Block mit den gemessenen Zahlen.
- **Keine Semikolon-Ketten.** Ein Gedanke, ein Satz.
- Technisch der eigentliche Auslöser: die Nachricht kam aus **einem einzigen `-m`**. Künftig `git commit -F <datei>` oder ein `-m` je Absatz.
## Bestehende Texte: nicht angefasst
Entscheidung so getroffen, nachdem ich die Kosten gemessen habe: **348 echte Commit-Hashes dieses Repos stehen in 193 Issues und Kommentaren** (alle 376 Issue- und Kommentartexte durchsucht, die Treffer gegen die echte Hash-Liste geprüft), dazu die Fußzeilen der importierten Notizen und die Hashes im Wiki. Ein `filter-repo` plus Force-Push würde jeden dieser Hashes ändern, und Gitea verlinkt sie heute automatisch — danach zeigt keiner mehr irgendwohin. Die Spur von Issue zu Code ist das, was die alten Nachrichten überhaupt brauchbar macht.
Also: **kein `filter-repo`, kein Force-Push.** Die Regel gilt nur nach vorne.
## Der erste Beleg
Der Wiki-Commit `639f190` ist selbst im neuen Format geschrieben (Betreff 45 Zeichen, Leerzeile, Absätze, `Tests:`-Zeile), ebenso die Commits zu #129 Etappe 3, die gerade entstehen — Betreff 57 Zeichen statt 3316.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Du erstellst Commits mit Text wo alles in einer Wurst ist. Bitte zukünftig vermeiden. bisschen mehr Struktur (Absätze, Aufzählungen, etc.)
Ist es auch möglich schon vorhandene Commit-Text zu überarbeiten?
Umgesetzt — ab jetzt gilt die Regel, die History bleibt unangetastet.
Der Befund, gemessen an der echten History
cb1804d)Das Wiki-Repo hat dasselbe Muster. Jede Log-Ansicht schneidet an der ersten Zeile ab —
git log --oneline, die Gitea-Historie, der Viewer im Screenshot. Eine 3316-Zeichen-Zeile ist damit nicht unschön, sondern unlesbar.Die Regel
Steht im Wiki unter Development → Commit messages (
639f190), dazu in der Projektnotiz und in der globalen Memory, damit sie in jedem Repo gilt:Tests:-Block mit den gemessenen Zahlen.-m. Künftiggit commit -F <datei>oder ein-mje Absatz.Bestehende Texte: nicht angefasst
Entscheidung so getroffen, nachdem ich die Kosten gemessen habe: 348 echte Commit-Hashes dieses Repos stehen in 193 Issues und Kommentaren (alle 376 Issue- und Kommentartexte durchsucht, die Treffer gegen die echte Hash-Liste geprüft), dazu die Fußzeilen der importierten Notizen und die Hashes im Wiki. Ein
filter-repoplus Force-Push würde jeden dieser Hashes ändern, und Gitea verlinkt sie heute automatisch — danach zeigt keiner mehr irgendwohin. Die Spur von Issue zu Code ist das, was die alten Nachrichten überhaupt brauchbar macht.Also: kein
filter-repo, kein Force-Push. Die Regel gilt nur nach vorne.Der erste Beleg
Der Wiki-Commit
639f190ist selbst im neuen Format geschrieben (Betreff 45 Zeichen, Leerzeile, Absätze,Tests:-Zeile), ebenso die Commits zu #129 Etappe 3, die gerade entstehen — Betreff 57 Zeichen statt 3316.