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 <newren@xxxxxxxxx> writes: > >> 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.
