Includism: Remove `.*`

##  Abstract

Currently, the `*.gitignores` in this repository imply what can be described as an *excludistic* policy on files and directories starting with a `.`, by basically ignoring all of them and then un-ignoring some of them. As becomes evident when thinking common scenarios through, this burdens the user to either circumventing this policy or circumventing Git. In either case the user is left on his own, without support from the ignore policy or the VCS.

##  Case Studies

The following two case studies try to make the train of thought leading to this conclusion comprehensible.

### Status Quo: Excludistic Approach

-   Approach: Ignore all hidden files, watch some hidden files.
-   Implementation: `.*` and `!.gitignore`, `!.htaccess` etc.
-   Use Cases:
    -   private backups
        -   Goal: Version control everything under `~/`.
        -   Problem: Settings files and folders under `~` start with a `.`.
        -   Examples: `~/.vimrc`, `~/.ssh/`
        -   Solution: Technically none.  
            (It was assumed that not all of these files are to be watched.)
        -   Workaround:
            -   Put the Git root at `~/`.
            -   Put `!.*` at the end of the `.gitignore`.
    -   open source projects
        -   Goal: Publicize software using Git.
        -   Problem: Some files starting with a `.` need to be tracked.
        -   Examples: `.htaccess`
        -   Solution:
            -   Put the Git root at the project root.
            -   Add unignores for everything to be publicized. E.g. `!.htaccess`.
        -   But: New files like this will not show up in `git status`.
        -   Workaround:
            -   Put the Git root at the project root.
            -   Watch all files/folders with `!/*`.
            -   Add ignores for private files using `git status`.

###  Proposal: Includistic Approach

-   Approach: Ignore hidden files that should not be watched, only.
-   Implementation: `!.*` (or nothing at all) and e.g. `.htpasswd`.
-   Use Cases:
    -   private backups
        -   Goal: Version control everything under `~/`.
        -   Problem: Settings files and folders under `~` start with a `.`.
        -   Examples: `~/.vimrc`, `~/.ssh/`
        -   Solution:
            -   Put the Git root at `~`.
            -   `git add .`
    -   open source projects
        -   Goal: Publicize software using Git.
        -   Problem: Some files starting with a `.` containing sensitive data need to be ignored.
        -   Examples: `.htpasswd`
        -   Solution:
            -   Put the Git root at the project root.
            -   Use `git status` to list all files.
            -   Decide whether to `git add` or to add an ignore for each file.

##  Backtrace

The file [`/PlayFramework.gitignore`](https://github.com/github/gitignore/blob/e605ce745a224050de763e1139244795362fa99e/PlayFramework.gitignore) still has a comment stating that it was copied from [a small project with only one hidden file in the repository](https://github.com/ulrich/macaron-factory). - The `.gitignore`. In such cases, adding `.*` and `!.gitignore`to the ignores does the trick and keeps necessary files under version control while sparing the user noise in `git status`. So this rule might be the obvious choice in many situations, because the exceptions are reasonably few.

##  Known Opinions

This issue has some background that can be traced in this repository. In chronological order:

-    3 years ago, [@nu7hatch stated](https://github.com/github/gitignore/commit/534d7da8b6e1919373c538d40488ba52b0ebc3d9#Global/Linux.gitignore)  stated that `.*` is 'too ambiguous'.
-   3 years ago, [@andyhausmann and @MaxNanasy stated](https://github.com/github/gitignore/commit/91a1756d29131c38599af43e417b15a2340f7d6e) that `.*` should be removed in favor of more specfic ignores.
-   1 day ago, [@jspahrsummers and I agreed](https://github.com/github/gitignore/pull/687#issuecomment-20424815)  that trying to appy the excludistic approach is ultimately infesibile because there are to many cases in which `.*` could be wrong.