Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > 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. Yes, this is one of the two remaining things that still make me a bit worried about the "$.config" syntax. > 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. True, too. The other one that still make me a bit worried about the "$.config" syntax is what I called "the devil you already know" that is applicable only for participants of a project that currently mark precious files as ignored, to avoid the accidental "git add ." of secrets. I think we already are in agreement that all other points (aside from possible ergonomics preferences and future extensibility, both feel a lot minor) raised during this discussion are in favor of the "$.config" 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. True. The parser can be isolated and it should be relatively easy to revamp. My current preference is to (at least) tentatively agree on using the "$.config" syntax, which would allow us to update dir.c:parse_path_pattern(), and that would make it possible for us to start adjusting dir.c:is_excluded(), adding is_precious() next to it, and adjusting all current callers of the former. Thanks.
