Support for Hidden files

[AnthonyVadala]

There are proposed standards and one major use case (outside of GitHub), I am aware of, that are legitimate use cases for serving hidden files.

RFC 5785 - defines a path prefix for "well-known locations", /.well-known/, in selected Uniform Resource Identifier (URI) schemes.

security.txt | draft - defines a format ("security.txt") to help organizations describe the process for security researchers to follow in order to report security vulnerabilities.

Let's Encrypt also uses the ./well-known/ hidden directory, which usually points to /.well-known/acme-challenge.

[mkropat]

Thanks for starting this discussion.

All good examples. One other example that comes to mind is .htaccess.

Are there hidden files that we definitely don't want to publish? The one example that prompted me to omit hidden files in the first place is the .git/ directory. I suspect there may be other examples.

If it's true that there are some hidden files that we do want to publish and some we don't, then what do people think is the best path forward?

• Blacklist/exclude specific bad paths (such as .git/, perhaps anything listed in .gitignore, etc.)
• Whitelist/include specific, useful paths (such as the ones listed in this issue)
• Some other approach entirely?

[AnthonyVadala]

I would say to follow the gitignore templates and add OS generated files to the definitely don't want to publish list.

OS Generated Files

.DS_Store
.DS_Store?
._*
.Spotlight-V100
.Trashes
ehthumbs.db
Thumbs.db

I would say a blacklist based approach would be best, so you don't break what users expect to happen when committing.