Re: [RFC] Define "precious" attribute and support it in `git clean`

I liked the idea too see precious files as sub-class of ignored files, and investigated possibilities on how to achieve that while keeping the overall effort low and remove any potential for backwards-incompatibility as well.

Currently, `.gitignore` files only contain one pattern per line, which
optionally may be prefixed with `!` to negate it. This can be escaped with `\!`
- and that's it.

Parsing patterns that way makes for simple parsing without a need for quoting.

### What about a `$` syntax in `.gitignore` files?

I looked into adding a new prefix, `$` to indicate the following path is precious or… valuable. It can be escaped with `\$` just like `\!`.

Doing so has the advantage that older `git` versions simply take the declaration as literal and would now exclude `$.config`, for example, whereas newer `git` versions will consider them precious.

There is some potential for accidentally excluding files that previously were untracked with older versions of git, but I'd think chances are low.

#### Example: Linux kernel

`.config` is ignored via `.gitignore: 

    .*

*Unfortunately*, users can't just add a local `.git/info/exclude` file with `$.config` in it and expect `.config` to be considered precious as the pattern search order will search this last as it's part of the exclude-globals. The same is true for per-user git-ignore files. This means that any git would have the `.*` pattern match before the `$.config` pattern, and stop right there concluding that it's expendable, instead of precious. This is how users can expect `.gitignore` files to work, and this is how `!negations` work as well - the negation has to come after the actual exclusion to be effective.

Thus, to make this work, projects that ship the `.gitignore` files would *have to add patterns* that make certain files precious.

Alternatively, users have to specify gitignore-overrides on the command-line, but not all commands (if any except for `git check-ignore`) support that.

In the case of `git clean` one can already pass `--exclude=pattern`, but if that's needed one doesn't need syntax for precious files in the first place.

**This makes the $precious syntax useful only for projects who chose to opt in, but makes overrides for users near impossible**.

Such opted-in projects would produce `.gitignore` files like these:

    .*
    $.config

Note that due to the way ignore patterns are searched, the following would consider `.config` trackable, not precious:

    .*
    $.config
    !.config

It's up the maintainer of the repository to configure their .gitignore files correctly, so nothing new either.

#### Benefits

* simple implementation, fast
* backwards compatible

#### Disadvantages

* cannot easily be overridden by the user as part of their local settings.
* needs repository-buy-in to be useful
* $file could clash with the file '$file' and cause older git  to ignore it

### What about a `precious` attribute?

The search of `.gitattributes` works differently which makes it possible for users to set attributes on any file or folder easily using their local files. Using attributes has the added benefit of being extensible as one can start out with:

```gitattributes .config precious ```

and optionally continue with…

```gitattributes .config precious=input kernel precious=output ```

…to further classify kinds of precious files, probably for their personal use. Please note that currently pathspecs can't be used to filter by attribute for files that are igonred and untracked or I couldn't figure out how. That even makes sense as it wasn't considered a use-case yet.

#### Benefits

* backwards compatible
* easily extendable with 'tags' or sub-classes of precious files using the
  assignment syntax.
* overridable with user's local files

#### Disadvantages

* any 'exclude' query now also needs a .gitattribute query to support precious
  files (and it's not easy to optimize unless there is a flag to turn precious
  file support on or off)
* `precious` might be in use by some repos which now gains a possibly different
  meaning in `git` as well.

### Conclusion

Weighing advantages and disadvantages of both approaches makes me prefer the `.gitignore` extension. The `.gitattributes` version of it *could* also be implemented on top of it at a later date. However, it should be gated behind a configuration flag so users who need it as they want local overrides can opt-in. Then they also pay for the feature which for most repositories won't be an issue in the first place.

All this seems a bit too good to be true, and I hope you can show where it wouldn't work or which dangers or possible issues haven't been mentioned yet.