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

From: Elijah Newren <newren@gmail.com>
Date: Jan 19, 2024, 02:58 UTC
Message-ID: <CABPp-BHaUDdtH6igDmOx_wv8xYh-uA=4L9zDDycrZLaa9c9KLQ@mail.gmail.com>
In-Reply-To: <xmqqwms6qwr3.fsf@gitster.g>

Hi,

On Thu, Jan 18, 2024 at 11:14 AM Junio C Hamano <gitster@pobox.com> wrote:

[...]

> So, all it boils down to is these two questions.

Thanks for summarizing this.

Show 6 quoted lines

>  * Which one between "'git add .' adds '.config' that users did not
>    want to add" and "'git clean -f' removes '.config' together with
>    other files" a larger problem to the users, who participate in a
>    project that already decided to use the new .gitignore feature to
>    mark ".config" as "precious", of older versions of Git that
>    predate "precious"?

Accidental "git add ." comes with 3 opportunities to correct the problem before it becomes permanent: before commiting, after committing but before pushing, and after publishing for patch review (where it can even be caught by third parties) but before the patch/PR/MR is accepted and included. At each stage there's a chance to go back and correct the problem.

Accidental nuking of a file (via either git clean or git checkout or git merge or whatever), cannot be reviewed or corrected; it's immediately too late. And given that we're calling this feature "precious", that seems a little extra unfortunate.

Show 6 quoted lines

>  * What are projects doing to paths that they want to make
>    "precious" with the current system?  Do they leave them out of
>    ".gitignore" and have them subject to accidental "git add ." to
>    protect them from "git clean -f"?  Or do they list them in
>    ".gitignore" to prevent "git add ." from touching, but leave them
>    susceptible to accidental removal by "git clean -f"?

Good questions; I have no answers to these.

However, on a closely related note, in my response to Sebastian I point out that the '$' syntax permits individual teams to prioritize avoiding either accidental deletions or accidental adds on a filename or glob granularity, so if folks are concerned with handling by older Git versions or are just extra concerned with certain files, they can optimize accordingly. Sadly, the '#(keep)' syntax does not permit such prioritization and always treats avoiding accidental adds as the priority (which, in my opinion, is the less important one to generally prioritze).