I don’t know exactly when, but at some point Sitecore introduced support in its ASP.NET Web Content Management for web.config include files. Include files allow administrators to define configuration in files separate from the main web.config file, which can simplify configuration, release management, and other aspects of the system.
A recent post on the Sitecore Developer Network demonstrated some confusion that can result from this feature. If you only look in the web.config file and not the include files that can override web.config, then you might not see the settings that actually take effect. I imagine this gets especially confusing if you allow multiple include files to override a single setting; I am not sure how Sitecore determines which setting in which include file to apply in such cases.
To help resolve such confusion, Sitecore provides a tool that allows you to investigate the effective configuration after it applies the include files. You can access this tool at the following URL on your server:
/sitecore/admin/showconfig.aspx
Note that for security, the Sitecore installer configures IIS to deny anonymous access to the /sitecore/admin subdirectory, so you may have to open access to this subdirectory in IIS. In production, you should require authentication to access the /sitecore/admin subdirectory, and/or restrict the IP range with access.
Unfortunately, the tool does not indicate which file defines the effective settings. So although it reduces the value of include files, to avoid confusion, I personally would try to use include files only to add settings and other elements that do not appear in the main web.config file. For instance, I would not use an include file to add a processor to one of the default pipelines, but I might use an include file to define an entire custom pipeline.
Update: The Detailed Config Report Sitecore shared source module appears to indicate which include files override settings.
John West Tech Blog 
Hmm.I would disagree with your recommended usage of config include files. My personal recommendation is to ONLY use config include files. This provides a seperation between core & default Sitecore settings and your own. This really helps when it comes time to upgrade as well. If I only put my settings in config include files then I can replace the old web.config with the new one without having to compare the files and reapply my updated settings. I can also distribute config updates in a package (you can\’t add web.config to a package or your package won\’t install). I know the extra level of abstraction can be confusing at first, but as soon as devs know they need to check the additional files for config settings I generally find there\’s no issue. Especially if you use a standard such as putting all project specific settings into a config include file. And as you point out, the showconfig tool helps developers see the effective settings for the application.
Not sure I agree on this one either John. Whenever I can, I try to avoid touching the web.config file at all. Anyone (and I think most of us working with Sitecore has at some point) who\’s ever taken the path through 5 or 6 version updates of a solution and step by step gone through web.config file changes will appreciate just being able to replace the web.config entirely and rely on include functionality for custom changes that the project requires.Also, as Alistair points out, packaging up something and deploying it all in one go – custom processors or otherwise – is absolutely excellent.Bump for the feature idea/request however, that the showConfig.aspx tool displays the actual source file that is currently in use for any setting however 🙂
Regarding the comments…I should mention that I have no production experience with Sitecore, only theoretical and support knowledge. So I defer to the experts, but I will leave the comment in the post for context.