Message ID | c1c83c4284ba4b041694a521c3639f33561ac5e3.1658255537.git.gitgitgadget@gmail.com (mailing list archive) |
---|---|
State | Accepted |
Commit | 559c2c3d2a34c4d8c24265e118175f55771112a2 |
Headers | show |
Series | Remove use of "whitelist" | expand |
On Tue, Jul 19, 2022 at 06:32:15PM +0000, Derrick Stolee via GitGitGadget wrote: > From: Derrick Stolee <derrickstolee@github.com> > > The documentation for GIT_ALLOW_PROTOCOL has a sentence that adds no > value, since it repeats the meaning from the previous sentence (twice!). I think the point the original was trying to make was emphasizing that when the variable is set at all, then we operate in this new mode. Maybe that's sufficiently conveyed in the first sentence, but perhaps another way of expanding would be: If the variable is unset, it has no effect, and the normal configuration is respected. But perhaps that is obvious enough from the previous sentence. Since I was involved in drafting the original, I'm not sure I'm a good judge of what is obvious and what is not. :) -Peff
diff --git a/Documentation/git.txt b/Documentation/git.txt index 302607a4967..47a6095ff40 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -885,9 +885,7 @@ for full details. If set to a colon-separated list of protocols, behave as if `protocol.allow` is set to `never`, and each of the listed protocols has `protocol.<name>.allow` set to `always` - (overriding any existing configuration). In other words, any - protocol not mentioned will be disallowed (i.e., this is a - whitelist, not a blacklist). See the description of + (overriding any existing configuration). See the description of `protocol.allow` in linkgit:git-config[1] for more details. `GIT_PROTOCOL_FROM_USER`::