Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: > I think comparing this habit to the .gitignore isn't quite fair - > .gitignore tells me I forgot to add my new command binary to it, when I > run `git status` to see what I need to add to my commit with new > command. That is why I said that we need to actively work on, if we care about getting quality reports. I do not think it is unreasonable to expect the build procedure for "git bugreport" to involve scanning in Documentation/config/ to pick up variable names, annotated in such a way that is invisible to AsciiDoc to allow us tell which ones are sensitive and which ones are not. A test in t/ could even check if a documented configuration variable has such an annotation. A commit that adds configuration variables without documentiong them does exist, but variables without documentation are (1) bugs, and (2) are not worth serious engineering effort on until they get documented. I am not saying that you must implement the whitelist exactly like the above. I am not even saying that this must be whitelist and not blacklist---you'd have the same issue maintaining the list anyway. The above is merely to illustrate the reason why I think that the kind of "active work" to make sure that the list will not go stale would be feasible. Thanks.
