### Overview In our Push Rule models (`PushRule`, `GroupPushRule`, and `OrganizationPushRule`), we currently implement a three-state setting system using nullable boolean columns: ``` true: explicitly enabled false: explicitly disabled NULL: inherit from global settings ``` This approach allows settings to cascade from global to group to project level using custom getters and setters in the model. ### Current challenges While this implementation works functionally, it presents several challenges: - Database semantics: Using `NULL` to represent "inherit" overloads the typical meaning of `NULL` in databases - Schema clarity: The database schema alone doesn't communicate the special meaning of these nullable columns - Query limitations: Writing SQL queries against these columns requires special `NULL` handling ### Questions to consider - What is the most clear and maintainable approach to replace the current multi-state boolean? - What would be the migration path from the current implementation? - Are there performance implications to consider? - How would each approach affect query complexity? ### Scope This pattern appears in several settings fields across Push Rule models, including: `reject_unsigned_commits`, `commit_committer_check`, `reject_non_dco_commits` and `deny_delete_tag` ### Note This was identified during the implementation of `GroupPushRule` and `OrganizationPushRule`. We decided to maintain the existing pattern for those models to ensure a safe migration path, with the intention to revisit this design holistically in the future.