Re: [PATCH] bugreport: add tool to generate debugging info

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 16, 2019, 16:41 UTC
Message-ID: <xmqqpnl512re.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190816012519.GF208753@google.com>

Emily Shaffer <emilyshaffer@google.com> 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.