From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Elijah Newren <newren@gmail.com>,
Sebastian Thiel <sebastian.thiel@icloud.com>,
Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Josh Triplett <josh@joshtriplett.org>
Subject: Re: [PATCH] precious-files.txt: new document proposing new precious file type
Date: Fri, 19 Jan 2024 09:17:32 -0800 [thread overview]
Message-ID: <xmqq1qadmedv.fsf@gitster.g> (raw)
In-Reply-To: <7fc35078-a165-4b3c-96e2-37fbe55e109d@gmail.com> (Phillip Wood's message of "Fri, 19 Jan 2024 16:53:50 +0000")
Phillip Wood <phillip.wood123@gmail.com> 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.
next prev parent reply other threads:[~2024-01-19 17:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-27 2:25 [PATCH] precious-files.txt: new document proposing new precious file type Elijah Newren via GitGitGadget
2023-12-27 5:28 ` Junio C Hamano
2023-12-27 6:54 ` Elijah Newren
2023-12-27 22:15 ` Junio C Hamano
2024-01-18 7:51 ` Sebastian Thiel
2024-01-18 19:14 ` Junio C Hamano
2024-01-18 21:33 ` Sebastian Thiel
2024-01-19 2:37 ` Elijah Newren
2024-01-19 7:51 ` Sebastian Thiel
2024-01-19 18:45 ` Junio C Hamano
2024-01-19 2:58 ` Elijah Newren
2024-01-19 16:53 ` Phillip Wood
2024-01-19 17:17 ` Junio C Hamano [this message]
2024-01-24 6:50 ` Elijah Newren
2024-02-11 22:08 ` Sebastian Thiel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq1qadmedv.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=josh@joshtriplett.org \
--cc=newren@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=sebastian.thiel@icloud.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).