Ivan Shapovalov <intelfx@xxxxxxxxxxxx> 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.
