Yes, indeed I was a little confused when making the "git commit..." based examples, thanks for correcting them. > > Reminds me of https://www.emacswiki.org/pics/static/TabsSpacesBoth.png > > ;-) > 😅 > Besides, if for a specific file or filetype, accidental additions are > more important to protect against than accidental nuking, then can't > folks achieve that by simply using > > # Don't let older git versions add the file > .env.secret > > # For newer git versions, override the above; treat it as precious > (i.e. don't add AND don't accidentally nuke) > $.env.secret > > In contrast, if protection against accidental nuking is more important > for certain files, one can use just the second line without the first. > I am glad I can pull my initial proposition of 'having both syntaxes' off the table to side with this version - it's gorgeous. It's easy to forget that the search-order when matching ignore patterns is back to front, which makes this 'trick' work. If the insights gained with the last couple of emails would see their digest in the user-facing documentation, I think precious files wouldn't only become usable but would also allow projects to make the their choice during the transition period during which some users will inevitably access the repository with a Git that doesn't know about precious files yet.
