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.
