Stop documenting the pre-rename fallback for users

Exactly one repository is configured with the old names, and it is
migrated by hand in the same move as this release. The fallback is
therefore a transition of days, not a feature anyone reading the release
notes or the configuration reference has to plan around.

Removed from `releases.html` and `docs/configuration.md`. The mechanism
itself is unchanged and stays described where it is worked on: in
`ConfigFiles`, in `StateDirMigration`, and in the migration plan.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
mhoennig
2026-08-31 07:14:35 +02:00
co-authored by Claude Opus 5
parent f7f59aa70b
commit 9af7a1efa4
2 changed files with 0 additions and 22 deletions
-5
View File
@@ -12,11 +12,6 @@ Werkator is configured via YAML files. Settings are merged from several sources
The repo install config (`.git/werkator/.werkator.yml`) wins on any key present in both files. Typically used to set `git.token` and `git.account` without committing them.
Each of the three is also looked up under the name it had before the rename to Werkator, spelled exactly as it was: `.gittally.yml` at the repository root and in a build worktree, `.git/gittally/.gittally.yml` for the machine layer.
The current name always wins; where both exist the old file is ignored, never merged.
The fallback exists because a missing configuration is not an error — it leaves every setting at its default, so an installation that updated without moving its files would come up looking healthy while having forgotten its credentials and its builds.
Rename the files at your convenience; the fallback goes away with a future release.
### Which Werkator a file is written for
Every configuration file may declare the Werkator it was written for. Without it, a