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

From: Elijah Newren <newren@gmail.com>
Date: Jan 19, 2024, 02:37 UTC
Message-ID: <CABPp-BF4Bfr3Hfy7atehHvbQds63+GXO9XPJAW3Mb7dvMcCkDg@mail.gmail.com>
In-Reply-To: <F214D88E-6837-4EAB-896E-DF8CFC315EE7@icloud.com>

On Thu, Jan 18, 2024 at 1:33 PM Sebastian Thiel <sebastian.thiel@icloud.com> wrote:

Show 9 quoted lines

>
> 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.

Show 10 quoted lines

> 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.