I thought it would be helpful to see the syntax being referred to here,
as first brought up by Phillip Wood:

#(keep)
/my-precious-file

The main benefit I see for it is that it's extensible, despite having
trouble imagining what such extension would be 10 years from now.
On the flip side, since it's already using a comment, people will
be even more inclined to document the reason for the preciousness
of the file.

# The kernel configuration, typically created by running a TUI program
#(keep)
.config

As a side-effect of the syntax, it's obvious this is an 'upgrade', with
perfect backwards compatibility as old git does the same as always.

I'd love to take first steps into the implementation, and if the above
should be the syntax to use, I'd be happy to submit a patch for parsing
it, along with initial support for precious files in `git clean` and
`git status`.

Does that sound like a reasonable next step?


On 27 Dec 2023, at 23:15, Junio C Hamano wrote:

Elijah Newren [off-list ref] writes:

quoted

There are
precisely two choices in our design for how older Git versions can
treat precious files:
  * ignored-and-expendable
  * untracked-and-precious
If we pick syntax that causes older Git versions to treat precious
files as ignored-and-expendable, we risk deleting important files.

Yes but not really.  I'd expect the adoption of precious feature and
the adoption of versions of Git that supports that feature will go
more or less hand in hand.  Projects that, for any reason, need to
keep their participants at pre-precious versions of Git would
naturally refrain from marking the "precious" paths in their "ignore"
mechanism before their participants are ready, so even if we chose
syntax that will make the precious ones mistaken as merely ignored,
the damage would be fairly small.