From: Junio C Hamano <gitster@pobox•com>
To: Ivan Shapovalov <intelfx@intelfx•name>
Cc: git@vger•kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail•com>
Subject: Re: [PATCH 0/3] clean: add `config.exclude` and `--remove-excluded`
Date: Tue, 11 Feb 2025 10:37:47 -0800 [thread overview]
Message-ID: <xmqqcyfoxr7o.fsf@gitster.g> (raw)
In-Reply-To: <20250210191504.309661-1-intelfx@intelfx.name> (Ivan Shapovalov's message of "Mon, 10 Feb 2025 23:14:36 +0400")
Ivan Shapovalov <intelfx@intelfx•name> writes:
> This series extends the concept of "excluded files" in `git clean` to
> make it useful to protect "precious files" that might be present in a
> specific developer's working tree (see below).
How does it interact with "git status"?
> Specifically, this series adds a `config.exclude` knob to configure
> "always excluded" files (same as `-e` on the command line), and a
> `--remove-excluded` flag (intentionally without a short form) to
> "REALLY remove everything, dammit!"
I am not sure if this uses the adjective `precious` to mean the same
thing as we historically talked about `precious`, in the context of
"Git does not have `precious files`. What we call `ignored` are
synoymous to `expendables`, and we'd eventually want to add the
`precious` class of files that are separate from `ignored` files".
If the feature is about _turning_ the existing `ignored/excluded`
into precious and require a new option to clean those files that
have always been treated as expendables, then that is a grave
usability regression. I am hoping that it is not the case.
Let's read on.
> This might seem like euphemism treadmill, but there is a specific
> use-case for all of the exclusion methods and options:
>
> .gitignore: files that _the project_ does not want to track or touch
> (build artifacts)
> clean.exclude: files that _the user_ does not want to track or touch
> (IDE configuration)
The above two share the same "does not want to track or touch"
explanation and readers do not know if you want them to have
distinct meaning, or just two different places the user has to store
the same information, one project-wide, given by and shared with
others, the other personal.
You need to say something like "`clean.exclude` introduces a new
`precious` class, the user does nto want to track or touch but
unlike those that match the patterns in .gitignore, they are not
expendables" here, if that is what you are trying to say (I am just
guessing).
Without that ...
> git clean -x: remove build artifacts, but keep precious files
> (when a pristine build is desired)
... this would merely be a wishful thinking, but once the reader
understands that you are introducing a new class, yes, it does make
sense. And it is backward compatible enhancement, which is very
good.
> git clean -x --remove-excluded:
> remove everything, including precious files
> (e.g. for redistribution)
Ditto.
Another common theme around `precious` is not IDE configuration but
things like config.mak file we have. Or perhaps deploy key files?
It is a clever UI hack to notice that the `precious` things are not
something you'd share with the project, and to take advantage of the
distinction between the project-wide vs personal preference in the
configuration system to introduce the `precious` class. For that,
it might even make sense to call the variable "clean.precious", as
its semantics is VASTLY different from what we called `exclude` or
`ignore` (they are synonyms---and they mean expendable files that
are not to be tracked).
And when people want non-project-wide but personal paths that are
excluded and expendable, they can use $GIT_DIR/info/exclude file.
So a possible alternative is to have the dir.[ch] infrastructure to
start paying attention to a new file $GIT_DIR/info/precious instead
of the configuration variables. I am not making an assessment on
the relative merit between clean.precious vs $GIT_DIR/info/precious
yet---just throwing an alternative for others to discuss.
By the way, I notice Ævar is CC'ed, but I haven't seen him for quite
a while around here, and am wondering how you decided to do so. Did
you have private conversations with and got suggestions from him or
something? Just being curious, but at the same time, if somebody's
influence in the resulting design is big enough, crediting them with
"Helped-by:" or some other trailer might be worth considering.
next prev parent reply other threads:[~2025-02-11 18:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-10 19:14 [PATCH 0/3] clean: add `config.exclude` and `--remove-excluded` Ivan Shapovalov
2025-02-10 19:14 ` [PATCH 1/3] clean, dir: add and use new helper `add_patterns_from_string_list()` Ivan Shapovalov
2025-02-10 19:14 ` [PATCH 2/3] clean: rename `ignored` -> `remove_ignored` Ivan Shapovalov
2025-02-10 19:14 ` [PATCH 3/3] clean: add `config.exclude` and `--remove-excluded` Ivan Shapovalov
2025-02-11 23:00 ` Junio C Hamano
2025-02-11 18:37 ` Junio C Hamano [this message]
2025-02-11 18:47 ` [PATCH 0/3] " Ivan Shapovalov
2025-02-11 21:24 ` Junio C Hamano
2025-02-11 21:42 ` Ivan Shapovalov
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=xmqqcyfoxr7o.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=avarab@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=intelfx@intelfx$(echo .)name \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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