Hi Elijah
On 19/01/2024 02:58, Elijah Newren wrote:
On Thu, Jan 18, 2024 at 11:14 AM Junio C Hamano <gitster@xxxxxxxxx> 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
