Re: [PATCH] precious-files.txt: new document proposing new precious file type

[Elijah Newren <newren@gmail.com>]

On Thu, Jan 18, 2024 at 1:33 PM Sebastian Thiel
<sebastian.thiel@icloud.com> wrote:
>
> Thanks so much for the analysis, as seeing the problem of choosing
> a syntax from the perspective of its effects when using common commands
> like "git add" and "git clean -f" seems very promising!
>
> When thinking about "git add ." vs "git clean -f" one difference comes to
> mind: "git clean -f" is much less desirable it's fatal. "git add ." on the
> other hand leaves room for correction, even when used with `git commit -a"
> (and with the exception of "git commit -am 'too late'").

"git commit -a" and "git commit -am 'too late'", by themselves, will
only commit changes to already-tracked files.  So they wouldn't be
problematic alone.

But perhaps the -a was distracting and you were thinking of "git add .
&& git commit -m whatever".  That does remove the chance to correct
before creating a commit, but I don't think it's too bad either.  Even
though it skips the chance to catch the problem pre-commit, there's
still time to review & correct before publishing for patch review (or
PR review or MR review or whatever you want to call it).  And, even if
published for patch review, it can still be caught & corrected by
those doing patch review as well.

So, I just don't see the "accidental add" problem as being very
severe; there are so many chances to catch and correct it.

> To my mind, in order to support projects with both ".config" and
> ".env.secret" they would have to be given a choice of which syntax
> to use, e.g.
>
>     # This file shouldn't accidentally be deleted by `git clean`
>     $.config
>
>     # These files should never be accidentally tracked
>     #(keep)
>     .env*

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.

And, whether you have a file with both lines or just the second line,
newer git versions will protect against both accidental nuking and
accidental adding.

In contrast...

Phillip's syntax provides no way to achieve treating accidental nuking
as more important than accidental adding; it can only handle
protection against accidental adding in older Git versions.  And, as I
discussed above, the accidental add problem seems much less severe and
is thus the less important problem to protect against.