* [PATCH 1/3] clean, dir: add and use new helper `add_patterns_from_string_list()`
2025-02-10 19:14 [PATCH 0/3] clean: add `config.exclude` and `--remove-excluded` Ivan Shapovalov
@ 2025-02-10 19:14 ` Ivan Shapovalov
2025-02-10 19:14 ` [PATCH 2/3] clean: rename `ignored` -> `remove_ignored` Ivan Shapovalov
` (2 subsequent siblings)
3 siblings, 0 replies; 9+ messages in thread
From: Ivan Shapovalov @ 2025-02-10 19:14 UTC (permalink / raw)
To: git; +Cc: Ivan Shapovalov, Ævar Arnfjörð Bjarmason,
Junio C Hamano
Signed-off-by: Ivan Shapovalov <intelfx@intelfx•name>
---
builtin/clean.c | 5 +----
dir.c | 15 +++++++++++++++
dir.h | 4 ++++
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 053c94fc6b..eaddf6a06e 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -931,7 +931,6 @@ int cmd_clean(int argc,
struct pathspec pathspec;
struct strbuf buf = STRBUF_INIT;
struct string_list exclude_list = STRING_LIST_INIT_NODUP;
- struct pattern_list *pl;
struct string_list_item *item;
const char *qname;
struct option options[] = {
@@ -1017,9 +1016,7 @@ int cmd_clean(int argc,
if (repo_read_index(the_repository) < 0)
die(_("index file corrupt"));
- pl = add_pattern_list(&dir, EXC_CMDL, "--exclude option");
- for (i = 0; i < exclude_list.nr; i++)
- add_pattern(exclude_list.items[i].string, "", 0, pl, -(i+1));
+ add_patterns_from_string_list(&dir, EXC_CMDL, "--exclude option", &exclude_list);
parse_pathspec(&pathspec, 0,
PATHSPEC_PREFER_CWD,
diff --git a/dir.c b/dir.c
index 5b2181e589..fa3fd53649 100644
--- a/dir.c
+++ b/dir.c
@@ -1263,6 +1263,21 @@ struct pattern_list *add_pattern_list(struct dir_struct *dir,
return pl;
}
+/*
+ * Convenience function to convert a string_list into pattern_list.
+ */
+struct pattern_list *add_patterns_from_string_list(struct dir_struct *dir,
+ int group_type,
+ const char *src,
+ struct string_list *sl)
+{
+ struct pattern_list *pl;
+ pl = add_pattern_list(dir, group_type, src);
+ for (int i = 0; i < sl->nr; i++)
+ add_pattern(sl->items[i].string, "", 0, pl, -(i+1));
+ return pl;
+}
+
/*
* Used to set up core.excludesfile and .git/info/exclude lists.
*/
diff --git a/dir.h b/dir.h
index a3a2f00f5d..eb843c9bb6 100644
--- a/dir.h
+++ b/dir.h
@@ -460,6 +460,10 @@ int hashmap_contains_parent(struct hashmap *map,
struct strbuf *buffer);
struct pattern_list *add_pattern_list(struct dir_struct *dir,
int group_type, const char *src);
+struct pattern_list *add_patterns_from_string_list(struct dir_struct *dir,
+ int group_type,
+ const char *src,
+ struct string_list *lst);
int add_patterns_from_file_to_list(const char *fname, const char *base, int baselen,
struct pattern_list *pl, struct index_state *istate,
unsigned flags);
--
2.48.1.5.g9188e14f140
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH 2/3] clean: rename `ignored` -> `remove_ignored`
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 ` Ivan Shapovalov
2025-02-10 19:14 ` [PATCH 3/3] clean: add `config.exclude` and `--remove-excluded` Ivan Shapovalov
2025-02-11 18:37 ` [PATCH 0/3] " Junio C Hamano
3 siblings, 0 replies; 9+ messages in thread
From: Ivan Shapovalov @ 2025-02-10 19:14 UTC (permalink / raw)
To: git; +Cc: Ivan Shapovalov, Junio C Hamano,
Ævar Arnfjörð Bjarmason
No behavior change.
Signed-off-by: Ivan Shapovalov <intelfx@intelfx•name>
---
builtin/clean.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index eaddf6a06e..ec58338049 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -923,7 +923,7 @@ int cmd_clean(int argc,
struct repository *repo UNUSED)
{
int i, res;
- int dry_run = 0, remove_directories = 0, quiet = 0, ignored = 0;
+ int dry_run = 0, remove_directories = 0, quiet = 0, remove_ignored = 0;
int ignored_only = 0, force = 0, errors = 0, gone = 1;
int rm_flags = REMOVE_DIR_KEEP_NESTED_GIT;
struct strbuf abs_path = STRBUF_INIT;
@@ -942,7 +942,7 @@ int cmd_clean(int argc,
N_("remove whole directories")),
OPT_CALLBACK_F('e', "exclude", &exclude_list, N_("pattern"),
N_("add <pattern> to ignore rules"), PARSE_OPT_NONEG, exclude_cb),
- OPT_BOOL('x', NULL, &ignored, N_("remove ignored files, too")),
+ OPT_BOOL('x', NULL, &remove_ignored, N_("remove ignored files, too")),
OPT_BOOL('X', NULL, &ignored_only,
N_("remove only ignored files")),
OPT_END()
@@ -963,9 +963,9 @@ int cmd_clean(int argc,
dir.flags |= DIR_SHOW_OTHER_DIRECTORIES;
- if (ignored && ignored_only)
+ if (remove_ignored && ignored_only)
die(_("options '%s' and '%s' cannot be used together"), "-x", "-X");
- if (!ignored)
+ if (!remove_ignored)
setup_standard_excludes(&dir);
if (ignored_only)
dir.flags |= DIR_SHOW_IGNORED;
@@ -995,7 +995,7 @@ int cmd_clean(int argc,
* recursing into a directory which is itself ignored.
*/
dir.flags |= DIR_SHOW_IGNORED_TOO;
- if (!ignored)
+ if (!remove_ignored)
dir.flags |= DIR_SHOW_IGNORED_TOO_MODE_MATCHING;
/*
--
2.48.1.5.g9188e14f140
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH 3/3] clean: add `config.exclude` and `--remove-excluded`
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 ` Ivan Shapovalov
2025-02-11 23:00 ` Junio C Hamano
2025-02-11 18:37 ` [PATCH 0/3] " Junio C Hamano
3 siblings, 1 reply; 9+ messages in thread
From: Ivan Shapovalov @ 2025-02-10 19:14 UTC (permalink / raw)
To: git; +Cc: Ivan Shapovalov, Ævar Arnfjörð Bjarmason,
Junio C Hamano
Add `config.exclude` to configure "always excluded" files (same as `-e`
on the command line), and `--remove-excluded` (intentionally without a
short form) to "REALLY remove everything, dammit!"
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)
git clean -x: remove build artifacts, but keep precious files
(when a pristine build is desired)
git clean -x --remove-excluded:
remove everything, including precious files
(e.g. for redistribution)
Signed-off-by: Ivan Shapovalov <intelfx@intelfx•name>
---
Documentation/config/clean.txt | 11 +++++++++++
Documentation/git-clean.txt | 22 +++++++++++++++-------
builtin/clean.c | 19 ++++++++++++++++---
3 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/Documentation/config/clean.txt b/Documentation/config/clean.txt
index c0188ead4e..eb64ad26fa 100644
--- a/Documentation/config/clean.txt
+++ b/Documentation/config/clean.txt
@@ -1,3 +1,14 @@
clean.requireForce::
A boolean to make git-clean refuse to delete files unless -f
is given. Defaults to true.
+
+clean.exclude::
+ Additional exclude patterns that have higher priority than the standard
+ linkgit:gitignore[5] rules and will be honored in (almost) all cases,
+ even if the `-x` or `-X` options are given. These patterns are intended
+ to be used for user-specific "precious" files such as IDE configuration
+ that must not be removed even if a pristine build is desired. This list
+ has the same priority and semantics as the `-e` command line option.
+
+ The `--remove-excluded` command line option can be used to disregard
+ these exclude patterns (intentionally no short form).
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index fd17165416..33d6fb7228 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -59,15 +59,10 @@ OPTIONS
Be quiet, only report errors, but not the files that are
successfully removed.
--e <pattern>::
---exclude=<pattern>::
- Use the given exclude pattern in addition to the standard ignore rules
- (see linkgit:gitignore[5]).
-
-x::
Don't use the standard ignore rules (see linkgit:gitignore[5]), but
- still use the ignore rules given with `-e` options from the command
- line. This allows removing all untracked
+ still use the ignore rules given with the `-e` command line option or the
+ `clean.exclude` configuration variable. This allows removing all untracked
files, including build products. This can be used (possibly in
conjunction with 'git restore' or 'git reset') to create a pristine
working directory to test a clean build.
@@ -76,6 +71,19 @@ OPTIONS
Remove only files ignored by Git. This may be useful to rebuild
everything from scratch, but keep manually created files.
+-e <pattern>::
+--exclude=<pattern>::
+ Use the given exclude pattern in addition to the standard ignore rules
+ (see linkgit:gitignore[5]). Exclude patterns can also be configured
+ using the `clean.exclude` configuration variable. These patterns have
+ higher priority than the `-x` or `-X` options and will be honored
+ even in their presence.
+
+--remove-excluded::
+ Disregard the additional exclude patterns provided by `-e` or the
+ configuration variable `clean.exclude`. This flag has the highest
+ priority and intentionally does not have a short form.
+
Interactive mode
----------------
When the command enters the interactive mode, it shows the
diff --git a/builtin/clean.c b/builtin/clean.c
index ec58338049..eae22a1ec7 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -29,6 +29,7 @@
static int require_force = -1; /* unset */
static int interactive;
static struct string_list del_list = STRING_LIST_INIT_DUP;
+static struct string_list config_exclude_list = STRING_LIST_INIT_DUP;
static unsigned int colopts;
static const char *const builtin_clean_usage[] = {
@@ -133,6 +134,11 @@ static int git_clean_config(const char *var, const char *value,
return 0;
}
+ if (!strcmp(var, "clean.exclude")) {
+ string_list_append(&config_exclude_list, value);
+ return 0;
+ }
+
if (git_color_config(var, value, cb) < 0)
return -1;
@@ -925,6 +931,7 @@ int cmd_clean(int argc,
int i, res;
int dry_run = 0, remove_directories = 0, quiet = 0, remove_ignored = 0;
int ignored_only = 0, force = 0, errors = 0, gone = 1;
+ int remove_excluded = 0;
int rm_flags = REMOVE_DIR_KEEP_NESTED_GIT;
struct strbuf abs_path = STRBUF_INIT;
struct dir_struct dir = DIR_INIT;
@@ -940,11 +947,13 @@ int cmd_clean(int argc,
OPT_BOOL('i', "interactive", &interactive, N_("interactive cleaning")),
OPT_BOOL('d', NULL, &remove_directories,
N_("remove whole directories")),
- OPT_CALLBACK_F('e', "exclude", &exclude_list, N_("pattern"),
- N_("add <pattern> to ignore rules"), PARSE_OPT_NONEG, exclude_cb),
OPT_BOOL('x', NULL, &remove_ignored, N_("remove ignored files, too")),
OPT_BOOL('X', NULL, &ignored_only,
N_("remove only ignored files")),
+ OPT_CALLBACK_F('e', "exclude", &exclude_list, N_("pattern"),
+ N_("always exclude <pattern> from cleaning (overrides -x)"), PARSE_OPT_NONEG, exclude_cb),
+ OPT_BOOL(0, "remove-excluded", &remove_excluded,
+ N_("remove excluded files, too (overrides -e and clean.exclude)")),
OPT_END()
};
@@ -1016,7 +1025,10 @@ int cmd_clean(int argc,
if (repo_read_index(the_repository) < 0)
die(_("index file corrupt"));
- add_patterns_from_string_list(&dir, EXC_CMDL, "--exclude option", &exclude_list);
+ if (!remove_excluded) {
+ add_patterns_from_string_list(&dir, EXC_CMDL, "--exclude option", &exclude_list);
+ add_patterns_from_string_list(&dir, EXC_CMDL, "clean.exclude", &config_exclude_list);
+ }
parse_pathspec(&pathspec, 0,
PATHSPEC_PREFER_CWD,
@@ -1091,6 +1103,7 @@ int cmd_clean(int argc,
strbuf_release(&buf);
string_list_clear(&del_list, 0);
string_list_clear(&exclude_list, 0);
+ string_list_clear(&config_exclude_list, 0);
clear_pathspec(&pathspec);
return (errors != 0);
}
--
2.48.1.5.g9188e14f140
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH 3/3] clean: add `config.exclude` and `--remove-excluded`
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
0 siblings, 0 replies; 9+ messages in thread
From: Junio C Hamano @ 2025-02-11 23:00 UTC (permalink / raw)
To: Ivan Shapovalov; +Cc: git, Ævar Arnfjörð Bjarmason
Ivan Shapovalov <intelfx@intelfx•name> writes:
> Add `config.exclude` to configure "always excluded" files (same as `-e`
> on the command line), and `--remove-excluded` (intentionally without a
> short form) to "REALLY remove everything, dammit!"
>
> 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)
> git clean -x: remove build artifacts, but keep precious files
> (when a pristine build is desired)
> git clean -x --remove-excluded:
> remove everything, including precious files
> (e.g. for redistribution)
>
> Signed-off-by: Ivan Shapovalov <intelfx@intelfx•name>
> ---
> Documentation/config/clean.txt | 11 +++++++++++
> Documentation/git-clean.txt | 22 +++++++++++++++-------
> builtin/clean.c | 19 ++++++++++++++++---
> 3 files changed, 42 insertions(+), 10 deletions(-)
A few comments on the proposed semantics.
- It is questionable to throw paths that match command line "-e"
patterns into the 'precious' class. It breaks backward
compatibility and established end-user expectations, doesn't it?
- It is nice to see that an effort is made to sift "excluded" into
two classes. The traditional "ignored/excluded are expendable,
so "git clean" will remove them, "git switch", when path F is
excluded and there is a file F, would remove it when it needs to
check out a tree that has paths under directory F. "git add F"
and "git add ." would not add it unless forced. We would want
another class of files `precious` that are ignored in the same
sense by "git add", but yet excempt from removal by "git clean"
and things like "git switch".
- On the other hand, it is a good idea to use a new source of
patterns that the command never paid attention to, like a new
configuration variable. Since nobody has ever used it for
"excluded and expendable", there is no risk of breaking end-user
expectations.
- This particular implementation falls far short of the ideal of
"precious files" class, though. Since "git clean" is the only
thing that pays attention to clean.exclude, "git add ." would
happily add those paths that match the pattern, and "git switch"
to check out a directory whose pathname matches the pattern would
happily nuke a precious file that is in the working tree at that
path.
Earlier discussions proposed extended syntax added to .gitignore
mechanism and relevant codepaths, not just "git clean", all pay
attention to the new "precious" paths, but one idea proposed by
this series that is much better than the previous designs is the
use of separate sources of patterns---we do not have to worry about
backward compatibility issues at all with that design.
In my earlier review, I said it was clever to recognize that
precious would be of personal nature, but I now realize that there
are valid reasons why projects may _know_ what paths are precious
and would want to distribute that knowledge to its participants.
For example, our project would benefit from having config.mak marked
as precious for everybody, so that nobody commits such a file by
mistake and then ask us to pull from them.
As a configuration variable does not propagate across repositories
by design, it would not work as a way for the project to share its
idea of what paths are in the "precious" class, so in addition to
the clean.exclude (which probably is a bad name, as (1) we want not
just clean but things like add and switch also pay attention to it,
and (2) the class it defines is distinct from "exclude", and would
want to have the word "precious" in it) variable, we'd probably need
to have a way to record them in tracked files, either in .gitignore
files using some extended syntax, or separate .gitprecious files.
Thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/3] clean: add `config.exclude` and `--remove-excluded`
2025-02-10 19:14 [PATCH 0/3] clean: add `config.exclude` and `--remove-excluded` Ivan Shapovalov
` (2 preceding siblings ...)
2025-02-10 19:14 ` [PATCH 3/3] clean: add `config.exclude` and `--remove-excluded` Ivan Shapovalov
@ 2025-02-11 18:37 ` Junio C Hamano
2025-02-11 18:47 ` Ivan Shapovalov
3 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2025-02-11 18:37 UTC (permalink / raw)
To: Ivan Shapovalov; +Cc: git, Ævar Arnfjörð Bjarmason
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 0/3] clean: add `config.exclude` and `--remove-excluded`
2025-02-11 18:37 ` [PATCH 0/3] " Junio C Hamano
@ 2025-02-11 18:47 ` Ivan Shapovalov
2025-02-11 21:24 ` Junio C Hamano
0 siblings, 1 reply; 9+ messages in thread
From: Ivan Shapovalov @ 2025-02-11 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ævar Arnfjörð Bjarmason
On 2025-02-11 at 10:37 -0800, Junio C Hamano wrote:
> 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"?
In the same way as `git clean -e`, i.e., there is no interaction.
>
> > 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".
There were no implications behind my usage of the word "precious".
>
> 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).
I don't think I'm trying to introduce any new fundamental concepts to
Git. This patch is merely extending an existing command line option
into a configuration knob, because I noticed myself passing the same
arguments over and over and eventually creating an alias that does
nothing but `git clean -e ...`, with the `-e` flag repeated a good 20
or so times.
>
> 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.
The above descriptions are just that, free-form descriptions to help
understand the intended use-case. I'm not sure I understand the reasons
behind the "wishful thinking" label applied here.
>
> Another common theme around `precious` is not IDE configuration but
> things like config.mak file we have. Or perhaps deploy key files?
config.mak is precisely one of such files that I now have in my own
`clean.exclude`.
>
> 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.
This email was part of the `perl contrib/contacts/git-contacts` output
for this patchset, as documented in Documentation/SubmittingPatches
and Documentation/MyFirstContribution.txt. Should I have not done that?
--
Ivan Shapovalov / intelfx /
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/3] clean: add `config.exclude` and `--remove-excluded`
2025-02-11 18:47 ` Ivan Shapovalov
@ 2025-02-11 21:24 ` Junio C Hamano
2025-02-11 21:42 ` Ivan Shapovalov
0 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2025-02-11 21:24 UTC (permalink / raw)
To: Ivan Shapovalov; +Cc: git, Ævar Arnfjörð Bjarmason
Ivan Shapovalov <intelfx@intelfx•name> writes:
> On 2025-02-11 at 10:37 -0800, Junio C Hamano wrote:
>> 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"?
>
> In the same way as `git clean -e`, i.e., there is no interaction.
That is dissapointing. I was hoping that "git status -u" would list
precious and ignored ones in two separate sections.
> There were no implications behind my usage of the word "precious".
Then you should ;-) We'd like to see us use the same language to
refer to the same concept within this same project (and more
importantly, avoid misleading people by calling two different things
with the same phrase).
> This email was part of the `perl contrib/contacts/git-contacts` output
> for this patchset, as documented in Documentation/SubmittingPatches
> and Documentation/MyFirstContribution.txt. Should I have not done that?
No, as I said, I was curious if he is getting involved with the
project back again behind the curtain.
Thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/3] clean: add `config.exclude` and `--remove-excluded`
2025-02-11 21:24 ` Junio C Hamano
@ 2025-02-11 21:42 ` Ivan Shapovalov
0 siblings, 0 replies; 9+ messages in thread
From: Ivan Shapovalov @ 2025-02-11 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ævar Arnfjörð Bjarmason
[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]
On 2025-02-11 at 13:24 -0800, Junio C Hamano wrote:
> Ivan Shapovalov <intelfx@intelfx•name> writes:
>
> > On 2025-02-11 at 10:37 -0800, Junio C Hamano wrote:
> > > 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"?
> >
> > In the same way as `git clean -e`, i.e., there is no interaction.
>
> That is dissapointing. I was hoping that "git status -u" would list
> precious and ignored ones in two separate sections.
Do I need to implement those interactions in order for this patch set
to be considered viable?
>
> > There were no implications behind my usage of the word "precious".
>
> Then you should ;-) We'd like to see us use the same language to
> refer to the same concept within this same project (and more
> importantly, avoid misleading people by calling two different things
> with the same phrase).
I did not intend to mislead anyone (as evident by the fact that I was
simply not aware of any preexisting connotations). I'd appreciate
suggestions for a replacement term.
--
Ivan Shapovalov / intelfx /
>
> > This email was part of the `perl contrib/contacts/git-contacts` output
> > for this patchset, as documented in Documentation/SubmittingPatches
> > and Documentation/MyFirstContribution.txt. Should I have not done that?
>
> No, as I said, I was curious if he is getting involved with the
> project back again behind the curtain.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 862 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread