From: Phillip Wood Date: Fri, 19 Jan 2024 16:53:50 GMT Subject: Re: [PATCH] precious-files.txt: new document proposing new precious file type Message-ID: <7fc35078-a165-4b3c-96e2-37fbe55e109d@gmail.com> In-Reply-To: Hi Elijah On 19/01/2024 02:58, Elijah Newren wrote: > On Thu, Jan 18, 2024 at 11:14 AM Junio C Hamano 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 >> * 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. > [...] > 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