Drew Northup <n1xim.email@xxxxxxxxx> writes: >> + Note that the GITWEB_CONFIG_SYSTEM system-wide configuration file is >> + only used for instances that lack per-instance configuration file. >> + You can use GITWEB_CONFIG_COMMON common system-wide configuration >> + file (normally /etc/gitweb-common.conf) to keep common default >> + settings that apply to all instances. Settings from per-instance or >> system-wide configuration file override those from common system-wide >> configuration file. > > That's the point of explaining SPECIFICALLY why the then current > behavior wasn't being replaced, and this other mechanism (which would > otherwise have no obvious reason for existing) was being introduced. In order to just pick and use the more appropriate one (or a useful combination of the two), a clean description of what each of them do without historical cruft is more readable and useful, isn't it? I would expect that most of them who are newly configuring a system would pick COMMON one and override per instance as needed, without touching the SYSTEM one (fallback default) after reading the above, and that is what we want to happen. Do you think sysadmins need a history lesson to understand why there are two different possibilities? For example, bash reads some but not all possible configuration files. I would expect .bashrc to be read even for login shells after reading .bash_login; alas, that is not what happens. The manual does not apologize that the authors now know better and understand that it is a stupid behaviour. The order the rc files are read is just described matter-of-factly, and it gives sufficient information without unnecessary backstory. I think the new text conveys the necessary information to the intended audience with more clarity without the history lesson or the record of your past frustration. Am I mistaken? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html