git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Kristoffer Haugsbakk <code@khaugsbakk.name>,
	Sebastian Thiel <sebastian.thiel@icloud.com>,
	git@vger.kernel.org
Subject: Re: [RFC] Define "precious" attribute and support it in `git clean`
Date: Tue, 10 Oct 2023 10:07:08 -0700	[thread overview]
Message-ID: <xmqqo7h6tnib.fsf@gitster.g> (raw)
In-Reply-To: <ZSVbUSRUQlNy0bj-@localhost> (Josh Triplett's message of "Tue, 10 Oct 2023 22:10:25 +0800")

Josh Triplett <josh@joshtriplett.org> writes:

> While I'd love for it to default to that and require an extra option to
> clean away precious files, I'd expect that that would break people's
> workflows and finger memory. If someone expects `git clean -x -d -f` to
> clean away everything, including `.config`, and then it leaves some
> files in place, that seems likely to cause problems. (Leaving aside that
> it might break scripted workflows.)

I thought the point of introducing the new "precious" class of
paths, in addition to the current "tracked", "ignored, untracked,
and expendable", "not ignored and untracked", is so that people can
do "git clean -x -d -f" and expect the ".config" that is marked as
"precious" to stay.  Before their Git learned the precious class, if
they marked ".config" as "ignored, untracked, and expendable", then
such an invocation of "clean" would have removed it, but if they add
it to the new "precious" class, their expectation ought to be that
precious ones are not removed, no?  Otherwise I am not quite sure
what the point of adding such a new protection is.

  reply	other threads:[~2023-10-10 17:07 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-10 12:37 [RFC] Define "precious" attribute and support it in `git clean` Sebastian Thiel
2023-10-10 13:38 ` Kristoffer Haugsbakk
2023-10-10 14:10   ` Josh Triplett
2023-10-10 17:07     ` Junio C Hamano [this message]
2023-10-12  8:47       ` Josh Triplett
2023-10-10 19:10     ` Kristoffer Haugsbakk
2023-10-12  9:04       ` Josh Triplett
2023-10-10 17:02 ` Junio C Hamano
2023-10-11 10:06   ` Richard Kerry
2023-10-11 22:40     ` Jeff King
2023-10-11 23:35     ` Junio C Hamano
2023-10-12 10:55   ` Sebastian Thiel
2023-10-12 16:58     ` Junio C Hamano
2023-10-13  9:09       ` Sebastian Thiel
2023-10-13 16:39         ` Junio C Hamano
2023-10-14  7:30           ` Sebastian Thiel
2023-10-13 10:06       ` Phillip Wood
2023-10-14 16:10         ` Junio C Hamano
2023-10-13 11:25       ` Oswald Buddenhagen
2023-10-14  5:59   ` Josh Triplett
2023-10-14 17:41     ` Junio C Hamano
2023-10-15  6:44     ` Elijah Newren
2023-10-15  7:33       ` Sebastian Thiel
2023-10-15 16:31         ` Junio C Hamano
2023-10-16  6:02           ` Sebastian Thiel
2023-10-23  7:15           ` Sebastian Thiel
2023-10-29  6:44             ` Elijah Newren
2023-10-11 21:41 ` Kristoffer Haugsbakk

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=xmqqo7h6tnib.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=code@khaugsbakk.name \
    --cc=git@vger.kernel.org \
    --cc=josh@joshtriplett.org \
    --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).