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

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Jan 19, 2024, 16:53 UTC
Message-ID: <7fc35078-a165-4b3c-96e2-37fbe55e109d@gmail.com>
In-Reply-To: <CABPp-BHaUDdtH6igDmOx_wv8xYh-uA=4L9zDDycrZLaa9c9KLQ@mail.gmail.com>

Hi Elijah

On 19/01/2024 02:58, Elijah Newren wrote:

Show 6 quoted lines

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

Yes, thank you Junio - I found it very helpful as well

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

If you've added a secret then catching it after you've published the patch for review is likely to be too late. I agree there are a couple of chances to catch it before that though.

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

Indeed, though "git clean" requires the user to pass a flag before it will delete anything does have a dry-run mode to check what's going to happen so there is an opportunity for users to avoid accidental deletions.

Show 7 quoted lines

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

That is an advantage. I do worry that the '$' syntax is unintuitive and will further add to the impression that git is hard to use. I think the choice comes down how much we are worried about the way older versions of git treat ".gitignore" files with the new syntax.

While I can see it would be helpful to settle the syntax question I think parsing the new syntax is a relatively small part of the work that needs to be done to implement precious files.

Best Wishes

Phillip