From: Josh Triplett <josh@joshtriplett.org>
To: Kristoffer Haugsbakk <code@khaugsbakk.name>
Cc: 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 22:10:25 +0800 [thread overview]
Message-ID: <ZSVbUSRUQlNy0bj-@localhost> (raw)
In-Reply-To: <98387b86-1732-42bc-9ac5-d64a6617b2db@app.fastmail.com>
On Tue, Oct 10, 2023 at 03:38:51PM +0200, Kristoffer Haugsbakk wrote:
> Hi Sebastian
>
> On Tue, Oct 10, 2023, at 14:37, Sebastian Thiel wrote:
> > This highlights precious files by calling them out, but doesn't change the
> > behaviour of existing flags. Instead, the new flag `-p` is added which lets
> > `git clean` spare precious files.
>
> Why can't `clean` preserve precious files by default? And then delete them
> as well with something like `--no-keep-precious`? Is there some backwards
> compatibility concern?
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.)
It seems safer to keep the existing behavior for existing options, and
add a new option for "remove everything except precious files".
next prev parent reply other threads:[~2023-10-10 14:10 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 [this message]
2023-10-10 17:07 ` Junio C Hamano
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=ZSVbUSRUQlNy0bj-@localhost \
--to=josh@joshtriplett.org \
--cc=code@khaugsbakk.name \
--cc=git@vger.kernel.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).