Feature: suppress copying files by configuration

[FrankHB]

I find no options to ignore specific files to be built. Similar problems for watch/serve commands were mentioned in #831, and the improvement of the [build] configuration was also suggested there. But I think this is still a different issue better to be tracked separately.

A workaround to this problem is to specify src to a subdirectory. This can work, but far from perfect. It is not pleasant for transition from a repository of documents (consisting of plenty of .md files in the root directory) already checked in, as moving the files from the root to the subdirectory leads to much noise in the VCS history.

(Moreover, relying on .gitignore is problematic. What if there is only .hgignore, for example?)

[FrankHB]

To be more specific, Butbucket serves the project wikis as Mercurial repositories, but the Markdown features are limited. So, I decide to rearrange the documents in some other forms (hopefully with HTML output). However, at least the original .md documents still work without any changes online. If mdbook does not copy files (like my local .hg directory) by default, I can just start to work by simply adding book.toml and SUMMARY.md. This is not possible without some dirty hacks, and the workaround mentioned above does not work well because it breaks the file layout and I have to edit some internal links to make sure it can still work as a wiki. Currently I work it around by symbolic links in a separate src directory out of the tree, which is still a bit annoying for maintenance.

[FrankHB]

Since the default behavior may be expected, I wish the configuration opt-in. This should not break any existing usage.

[tv42]

I would love to use src = "." and not have unnecessary things like my build script or .gitignore copied into the output directory.

This repository contains very little else than the markdown files, I want them to be front and center, not in a subdirectory.

[Bergmann89]

Any updates on this issue? Would love to have this feature too! :)

[sanmai-NL]

Can this be closed in favor of the more elaborated duplicate #1187?