Two constants defined the data directory mode (0o750) in two packages that both create DATA_DIR: internal/datadir and internal/database. They agreed, but nothing kept them agreeing.
This makes internal/datadir the single owner. Its dirPerm becomes an exported DirPerm, and internal/database consumes it in both spots that create the directory (database.go and webhook_db_manager.go), dropping its own dataDirPerm.
Why datadir owns it: guarding and creating DATA_DIR is the package's entire purpose. The dependency direction allows it — datadir imports only the standard library and the flock package, so database importing datadir introduces no cycle. The reverse would not fit, since datadir must stay free of the database package it protects.
Single-source guard: a comment on DirPerm names it as the one definition. I chose that over a test that scans the tree for a reappearing literal, because the comment survives refactoring and adds no machinery that inspects the tree instead of fixing it — matching the definition of done's "whichever is more likely to survive."
No behaviour changes: the mode value is identical, so directory permissions are unchanged.
Two constants defined the data directory mode (`0o750`) in two packages that both create `DATA_DIR`: `internal/datadir` and `internal/database`. They agreed, but nothing kept them agreeing.
This makes `internal/datadir` the single owner. Its `dirPerm` becomes an exported `DirPerm`, and `internal/database` consumes it in both spots that create the directory (`database.go` and `webhook_db_manager.go`), dropping its own `dataDirPerm`.
Why `datadir` owns it: guarding and creating `DATA_DIR` is the package's entire purpose. The dependency direction allows it — `datadir` imports only the standard library and the flock package, so `database` importing `datadir` introduces no cycle. The reverse would not fit, since `datadir` must stay free of the `database` package it protects.
Single-source guard: a comment on `DirPerm` names it as the one definition. I chose that over a test that scans the tree for a reappearing literal, because the comment survives refactoring and adds no machinery that inspects the tree instead of fixing it — matching the definition of done's "whichever is more likely to survive."
No behaviour changes: the mode value is identical, so directory permissions are unchanged.
Resolves https://git.eeqj.de/sneak/webhooker/issues/288
Model: opus-4-8
internal/datadir now owns the DATA_DIR mode as an exported constant,
DirPerm; internal/database consumes it in both places that create the
directory rather than keeping its own copy. datadir is the owner
because guarding and creating DATA_DIR is its whole purpose, and the
dependency runs the right way: datadir imports only the standard
library and the flock package, so database importing datadir adds no
cycle. A comment on DirPerm names it as the single source, chosen over
a source-scanning test because it survives refactoring and builds no
machinery that inspects the tree. The mode value is unchanged.
Model: opus-4-8
Consolidation is correct and minimal: internal/datadir exports DirPerm, internal/database consumes it in both directory-creating spots, the value is unchanged, the dependency direction is sound (datadir imports only the standard library and the flock package, so no cycle), the comment naming the single source is accurate, and make check is green on the head rebased onto current next.
Model: opus-4-8
Consolidation is correct and minimal: `internal/datadir` exports `DirPerm`, `internal/database` consumes it in both directory-creating spots, the value is unchanged, the dependency direction is sound (`datadir` imports only the standard library and the flock package, so no cycle), the comment naming the single source is accurate, and `make check` is green on the head rebased onto current `next`.
Model: opus-4-8
clawbot
merged commit 39afa69bfc into next2026-09-21 10:01:51 +02:00
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.
Two constants defined the data directory mode (
0o750) in two packages that both createDATA_DIR:internal/datadirandinternal/database. They agreed, but nothing kept them agreeing.This makes
internal/datadirthe single owner. ItsdirPermbecomes an exportedDirPerm, andinternal/databaseconsumes it in both spots that create the directory (database.goandwebhook_db_manager.go), dropping its owndataDirPerm.Why
datadirowns it: guarding and creatingDATA_DIRis the package's entire purpose. The dependency direction allows it —datadirimports only the standard library and the flock package, sodatabaseimportingdatadirintroduces no cycle. The reverse would not fit, sincedatadirmust stay free of thedatabasepackage it protects.Single-source guard: a comment on
DirPermnames it as the one definition. I chose that over a test that scans the tree for a reappearing literal, because the comment survives refactoring and adds no machinery that inspects the tree instead of fixing it — matching the definition of done's "whichever is more likely to survive."No behaviour changes: the mode value is identical, so directory permissions are unchanged.
Resolves #288
Model: opus-4-8
Consolidation is correct and minimal:
internal/datadirexportsDirPerm,internal/databaseconsumes it in both directory-creating spots, the value is unchanged, the dependency direction is sound (datadirimports only the standard library and the flock package, so no cycle), the comment naming the single source is accurate, andmake checkis green on the head rebased onto currentnext.Model: opus-4-8