The terms "allowlist" and "denylist" are self-defining. One "allows" things while the other "denies" things. These are better terms over "whitelist" and "blacklist" which require prior knowledge of the terms or cultural expectations around what each color "means". This series replaces (almost) all uses of these terms with allowlist and denylist. The only exceptions are in release notes for older Git versions. There is no meaningful functional change, although one logging message in daemon.c is changed and I'm unfamiliar with exactly how that might be consumed. Some recommend using "blocklist", but I personally prefer "denylist". To me, "blocking" something seems permanent. "Denying" something seems ephemeral and related to a specific request being denied due to some (possibly mutable) state. I'm open to suggestions here. There are many fewer replacements needed in this case. I did not make any change to our CodingGuidelines. Hopefully having clear usage throughout the codebase will be enough to promote using consistent terminology. Thanks, -Stolee Derrick Stolee (3): Documentation: use allowlist and denylist t/*: use allowlist *: use allowlist and denylist Documentation/git-cvsserver.txt | 2 +- Documentation/git-daemon.txt | 10 +++++----- Documentation/git.txt | 2 +- daemon.c | 8 ++++---- git-cvsserver.perl | 2 +- sha1dc/sha1.c | 12 ++++++------ t/README | 4 ++-- t/lib-proto-disable.sh | 6 +++--- t/t5812-proto-disable-http.sh | 2 +- t/t5815-submodule-protos.sh | 4 ++-- t/t9400-git-cvsserver-server.sh | 2 +- t/test-lib-functions.sh | 2 +- t/test-lib.sh | 2 +- transport.c | 8 ++++---- 14 files changed, 33 insertions(+), 33 deletions(-) base-commit: e4a4b31577c7419497ac30cebe30d755b97752c5 Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1274%2Fderrickstolee%2Fallow-deny-v1 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1274/derrickstolee/allow-deny-v1 Pull-Request: https://github.com/gitgitgadget/git/pull/1274 -- gitgitgadget
