Hi Phillip, On Fri, Jan 19, 2024 at 8:53 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: [...] > >> * 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. Ah, good point. > > 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. Yes, good point again for "git clean"; it does have one level of check before the operation users can take advantage of. The same cannot be said for the files nuked by checkout/merge/rebase/cherry-pick, though. > > [...] > > 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. Interesting, I thought the mixture of '!' as a prefix and '#(keep)' as a previous-line directive would be somewhat inconsistent and add further to the impression that git is hard to use, though I can also see your point that '$' as a prefix can as well. > 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. Oh, I agree it's a small part of the work, but as stated previously, I'm not doing that work (Sebastian is). I'm just trying to help avoid getting unintended consequences in the design, and to me this is an important edge case to consider, get an agreement on, and document in some fashion. Anyway, Junio seems to have weighed in with a tentative path forward, and everyone has been very good about bringing up additional considerations around this issue that are worth documenting in the design document, so I'll try to put together an update soon-ish.
